* Re: [PATCH 0/2] user-manual: reorganize the configuration steps
From: J. Bruce Fields @ 2009-10-14 2:49 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jonathan Nieder
In-Reply-To: <1255293786-17293-1-git-send-email-felipe.contreras@gmail.com>
On Sun, Oct 11, 2009 at 11:43:04PM +0300, Felipe Contreras wrote:
> This basically introduces the "getting started" section so users get familiar
> with the configuration from the get-go, and also, most people prefer to teach
> 'git config --global' to setup the user name and email. Here are a few
> examples:
I'm not personally a big fan of starting out with a "how to use
git-config" section, because it's not that difficult or important:
questions we get on this list suggest confusion about a lot of things,
but git configuration is rarely one of them (that I've noticed).
I'd rather just point people to the git-config man page the first time
we mention any git configuration. (And improve the man page if
necessary to ensure it's up to the job.)
If we have to do this, just keep it short....
--b.
>
> git tutorial:
> http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
>
> GNOME:
> http://live.gnome.org/Git/Developers
>
> SourceForge:
> http://sourceforge.net/apps/trac/sourceforge/wiki/Git
>
> github:
> http://help.github.com/git-email-settings/
>
> Felipe Contreras (2):
> user-manual: add global config section
> user-manual: simplify the user configuration
>
> Documentation/user-manual.txt | 35 ++++++++++++++++++++++++++++++-----
> 1 files changed, 30 insertions(+), 5 deletions(-)
>
^ permalink raw reply
* [PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-14 2:12 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta, 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.
Linkify the avatar icon in log/shortlog view because the icon is directly
adjacent to the name and thus more related. The same is not true
when in commit/tag view where the icon is farther away.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
This is on top of Giuseppe's fix esc_param patch.
gitweb/gitweb.css | 1 +
gitweb/gitweb.perl | 21 ++++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 8f68fe3..e2cd9d7 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -30,6 +30,7 @@ img.logo {
img.avatar {
vertical-align: middle;
+ border-width: 0px;
}
div.page_header {
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4b21ad2..bdf1037 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1602,8 +1602,12 @@ sub format_author_html {
my $co = shift;
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"},
+ git_get_avatar($co->{'author_email'}, -pad_after => 1) .
+ $author) .
+ "</$tag>";
}
# format git diff header line, i.e. "diff --(git|combined|cc) ..."
@@ -3372,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)
@@ -3394,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.g75846.dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: fix esc_param
From: Stephen Boyd @ 2009-10-14 1:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Junio C Hamano
In-Reply-To: <1255463496-21617-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> The custom CGI escaping done in esc_param failed to escape UTF-8
> properly. Fix by using CGI::escape on each sequence of matched
> characters instead of sprintf()ing a custom escaping for each byte.
>
> Additionally, the space -> + escape was being escaped due to greedy
> matching on the first substitution. Fix by adding space to the
> list of characters not handled on the first substitution.
>
> Finally, remove an unnecessary escaping of the + sign.
>
Signoff?
This works great for my purposes. Thanks.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jay Soffian @ 2009-10-14 1:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Thomas Rast, Euguess, Mikael Magnusson,
Matthieu Moy, git, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0910140117280.4985@pacific.mpi-cbg.de>
On Tue, Oct 13, 2009 at 7:22 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> At some point, trying to educate the user is not helpful but annoying. If
> Git already knows what I want, why does it not do it already? _That_ is
> the question I already hear in my ears.
Modify checkout so that the first commit while detached automatically
creates a branch. Perhaps the name is derived from the branch point,
or the user is prompted for a name.
This doesn't help with the original problem, which was that a user
attempted to checkout refs/remotes/origin/<name> by just saying 'git
checkout <name>' which I happen to think should work. A lot of what I
keep hearing in this thread seems to be in the vein of the perfect
being the enemy of the good.
That rambled a bit. Sorry.
j.
^ permalink raw reply
* Re: [PATCH] clone: Supply the right commit hash to post-checkout when -b is used
From: Jeff King @ 2009-10-14 0:06 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git, ranguvar
In-Reply-To: <20091013221109.GA30972@atjola.homenet>
On Wed, Oct 14, 2009 at 12:11:09AM +0200, Björn Steinbrink wrote:
> When we use -b <branch>, we may checkout something else than what the
> remote's HEAD references, but we still used remote_head to supply the
> new ref value to the post-checkout hook, which is wrong.
>
> So instead of using remote_head to find the value to be passed to the
> post-checkout hook, we have to use our_head_points_at, which is always
> correctly setup, even if -b is not used.
>
> This also fixes a segfault when "clone -b <branch>" is used with a
> remote repo that doesn't have a valid HEAD, as in such a case
> remote_head is NULL, but we still tried to access it.
>
> Reported-by: Devin Cofer <ranguvar@archlinux.us>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Jeff King <peff@peff.net>
Thanks.
When splitting remote_head versus our_head, I tried to find every use of
the remote head and pick the appropriate variable, but I think I just
missed this one. I gave the code another once-over and didn't see any
other spots that needed fixing.
-Peff
^ permalink raw reply
* Re: [PATCH v5 2/2] gitweb: append short hash ids to snapshot files
From: Jakub Narebski @ 2009-10-13 23:46 UTC (permalink / raw)
To: Mark Rada; +Cc: Junio C Hamano, git
In-Reply-To: <4AD34C93.20605@mailservices.uwaterloo.ca>
On Mon, 12 Oct 2009, Mark Rada wrote:
> On 09-10-05 6:06 AM, Jakub Narebski wrote:
>
>>> my $o_git_dir = $git_dir;
>>> my $retval = undef;
>>> $git_dir = "$projectroot/$project";
>>> - if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
>>> - my $head = <$fd>;
>>> + if (open my $fd, '-|', git_cmd(), 'rev-parse', '--verify', $hash) {
>>> + $hash = <$fd>;
>>> close $fd;
>>> - if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
>>> + if (defined $hash && $hash =~ /^([0-9a-fA-F]{40})$/) {
>>> + $retval = $1;
>>> + }
>>
>> I guess that you use "$retval = $1;" instead of just "$retval = $hash;"
>> because of similarities with git_get_short_hash, isn't it? Or it is just
>> following earlier code?
>
> Yeah, it is following earlier code, I did not change it,
Ah, that's O.K.
Although if you plan refactoring this, you might fix this bit of
inefficiency (no need for capturing).
> though the diff seems to think I added it, perhaps this is a bug with
> diff?
No, that is just diff being ambiguous, as there is more than one way
to generate diff of changes. Perhaps patience diff would produce
better results, perhaps not. It might mean that refactoring common
code is needed ;-)))))
>>> + }
>>> + if (defined $o_git_dir) {
>>> + $git_dir = $o_git_dir;
>>> + }
>>> + return $retval;
>>> +}
>>> +
>>> +# try and get a shorter hash id
>>> +sub git_get_short_hash {
>>> + my $project = shift;
>>> + my $hash = shift;
>>> + my $o_git_dir = $git_dir;
>>> + my $retval = undef;
>>> + $git_dir = "$projectroot/$project";
>>> + if (open my $fd, '-|', git_cmd(), 'rev-parse', '--short=7', $hash) {
>>> + $hash = <$fd>;
>>> + close $fd;
>>> + if (defined $hash && $hash =~ /^([0-9a-fA-F]{7,})$/) {
>>> $retval = $1;
>>> }
>>> }
>>
>> Note that git_get_full_hash (which additionally does verification) and
>> git_get_short_hash share much of code. Perhaps it might be worth to
>> avoid code duplication somehow? On the other hand it might be not worth
>> to complicate code by trying to extract common parts here...
>
> Hmm, I think it might be a good idea to just write a generic routine
> that takes a hash length as an extra parameter. Then the short and full
> hash fetching routines can just acts as wrappers.
Well, git_get_full_hash uses --verify, git_get_short_hash uses --short=7
(but perhaps it should also use --verify).
BTW. I think that checking that output of git-rev-parse is (shortened)
SHA-1 predates usage of --verify; with --verify is, I think, not
necessary:
--verify
The parameter given must be usable as a single, valid object name.
Otherwise barf and abort.
>>> @@ -5203,6 +5228,13 @@ sub git_snapshot {
>>> die_error(400, 'Object is not a tree-ish');
>>> }
>>>
>>> +
>>> + my $full_hash = git_get_full_hash($project, $hash);
>>> + if ($full_hash =~ /^$hash/) {
BTW, we can use
if (index($full_hash, $hash) == 0) {
instead. BTW, $hash could contain regexp metacharacters like '.'
('dead.beef' is a valid branch name), so it should be
if ($full_hash =~ /^\Q$hash/) {
if you want to use regexp (it might be easier to read).
Or you can encapsulate this into is_substring() subroutine, but that
might be (well, almost surely is) overkill...
>>> + $hash = git_get_short_hash($project, $hash);
>>> + } else {
>>> + $hash .= '-' . git_get_short_hash($project, $hash);
>>> + }
>>
>> I think we might want to avoid calling git_get_full_hash (and extra call
>> to "git rev-parse" command, which is extra fork) if we know in advance
>> that $full_hash =~ /^$hash/ can't be true, i.e. if $hash doesn't match
>> /^[0-9a-fA-F]+$/. That would require that we continue to use $hash
>> and not $full_hash, see comment for the chunk below.
>>
>> BTW do you think that having better name (nicer name in the case
>> when $hash is full SHA-1, or name which describes exact version as
>> in the case when $hash is branch name or just 'HEAD') is worth
>> slight extra cost of "git rev-parse --abbrev=7"?
>
> Hmm, yeah, some optimization will have to occur in that block of
> code. Though, my reason for that extra call to rev-parse to get the
> short hash is so I can get git to find the shortest unique SHA-1,
> instead of just assuming that it will always be of length 7. I think
> the cost is not too bad considering a snapshot will have to be generated
> and probably take way more time. Though, warthog9 has some caching
> patches that work, so maybe it isn't worth it. Hmm...
What I meant here that unless $hash =~ /^[0-9a-fA-F]{7,}$/ then we
always use git_get_short_hash, as $full_hash wouldn't match /^$hash/
($hash wouldn't be a prefix of $full_hash). We don't need to
calculate git_get_full_hash which wouldn't be used (see also comment
below, though).
>
>>> my $name = $project;
>>> $name =~ s,([^/])/*\.git$,$1,;
>>> $name = basename($name);
>>> @@ -5213,7 +5245,7 @@ sub git_snapshot {
>>> $cmd = quote_command(
>>> git_cmd(), 'archive',
>>> "--format=$known_snapshot_formats{$format}{'format'}",
>>> - "--prefix=$name/", $hash);
>>> + "--prefix=$name/", $full_hash);
>>
>> Why this change?
>
> Since $hash can change by becoming something like 'HEAD-43ab5f2c' due to
> the process of creating the better name we need to pass something to
> `archive' that will be valid, and $full_hash will be valid.
Errr... why it is called _$hash_ then, if it can be not hash? Wouldn't
it be better to manipulate $name here?
I think this fragment should be extracted into snapshot_name() subroutine,
which result would be used both as proposed snapshot name, and as prefix
to be used.
>
>>> +test_description='gitweb as standalone script (parsing script output).
>>> +
>>> +This test runs gitweb (git web interface) as a CGI script from the
>>> +commandline, and checks that it produces the correct output, either
>>> +in the HTTP header or the actual script output.'
>>
>> Currently all tests here are about 'snapshot' action. They are quite
>> specific, and they do require some knowledge about chosen archive format.
That is not true, as I haven't noticed at this point that you are
examining only HTTP headers... but not the HTTP status but other headers.
[...]
>>> + grep ".git-$ID.tar.gz" gitweb.output
>>
>> Here had to think a bit that gitweb.output consists both of HTTP headers,
>> and of response body, and you are grepping here in the HTTP headers part.
>> It would be better solution for gitweb_run to split gitweb.output into
>> gitweb.headers and gitweb.body (perhaps if requested by setting some
>> variable, e.g. GITWEB_SPLIT_OUTPUT).
>>
>> It can be done using the following lines:
>>
>> sed -e '/^\r$/' <gitweb.output>gitweb.headers
That was meant to be
>> sed -e '/^\r$/q' <gitweb.output >gitweb.headers
which means print (the default action) until single empty CRLF terminated
line, which ends HTTP headers.
>> sed -n -e '0,/^\r$/!p' <gitweb.output>gitweb.body
>>
>> # gitweb.headers is used to parse http headers
>> # gitweb.body is response without http headers
>>
>> But the second one uses GNU sed extension; I don't know how to write
>> it in more portable way.
>
> I like this and will try to find a way of setting this up without using
> GNU extensions.
Well, we do know that there always would be at least one header, so we
can use:
sed -n -e '1,/^\r$/!p' <gitweb.output >gitweb.body
But I'd prefer that somebody better versed in sed would come up with
solution to extract everything up to first empty CRLF terminated line,
and everything from such line till the end of file.
>> Note that to avoid ambiguities currently gitweb uses refs/heads/master
>> and refs/tags/SnapshotFileTests... but dealing with this issue should be
>> left, I think, for separate commit.
>>
>
> I do not understand what ambiguity exists, can you please explain this?
The problem I was thinking about is the following.
In commit bf901f8 (gitweb: disambiguate heads and tags withs the same
name, 2007-12-15) started to use refs/heads/<branch> and refs/tags/<tag>
instead of <branch> and <tag> because there was problem when there were
tag and branch with the same name.
The problem is that we can't use '/' in proposed snapshot file name,
and we shouldn't use '/' in git-archive prefix. So we can't simply
use (as you proposed)
$hash . '-' . git_get_short_hash($project, $hash);
as a snapshot basename suffix, because $hash can be 'refs/heads/master',
or it can be 'mr/gitweb-snapshot'. What to do, what to do...
Also if $hash is refs/tags/v1.6.0, we don't really need shortened SHA-1
suffix.
Alternative to checking for refs/tags/ prefix would be to use
git-describe output... perhaps.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-13 23:22 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, Euguess, Mikael Magnusson,
Matthieu Moy, Jay Soffian, git, Johannes Sixt
In-Reply-To: <20091013220640.GB12603@coredump.intra.peff.net>
Hi,
On Tue, 13 Oct 2009, Jeff King wrote:
> On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote:
>
> > So in my opinion, we should DWIM "git checkout $X" to mean "git checkout
> > -b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and
> > no other refs/remotes/$OTHER/$X.
>
> The similar suggestion that is less magical is to say something like
> "there is no $X; maybe you meant $REMOTE/$X?".
At some point, trying to educate the user is not helpful but annoying. If
Git already knows what I want, why does it not do it already? _That_ is
the question I already hear in my ears.
> Is there a reason not to phase in the behavior, to make sure it is not
> doing unexpected things?
Sure, I have nothing against that. But just insisting on the current
behavior, or on some behavior that is not helpful at all, well, is not
really clever.
Note that I am fully aware that my "git checkout -t origin/master" DWIMery
backfired quite badly. So I am in the same boat.
> In other words:
>
> 1. In v1.6.6, find all error-correcting candidates and print them as
> a suggestion (similar to what we do with "git foo").
>
> 2. Then, if we all agree that it seems to be producing sane results,
> the next step is to turn the unambiguous cases into a DWIM (and
> leave the ambiguous ones with the "did you mean?" message).
>
> Because right now I think there are a lot of hypothetical "maybe it
> would be less convenient or more confusing in this instance", but we
> don't have any data on how often those instances occur, or how actual
> users might react.
Oh, I do not want to spam the list with user experiences. But I do have
not only a faint idea how users react. Thankyouverymuch.
> So doing step (1) would be a way of collecting some of that data (will
> users say "stupid git, if you knew what I wanted, why didn't you just do
> it?" or "stupid git, your suggestion is just confusing me!").
I disagree. It is not about collecting data. We will not get any
feedback from the affected people. You know that, I know that.
The step (1) would help in the way that it is a smoother transition.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-13 23:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Daniel Barkalow, Johannes Sixt, Thomas Rast, Euguess,
Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <7vhbu2syi6.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:
> >
> >> I personally think that the real issue is that our "detached HEAD" message
> >> is still too scary, and what we really want is to issue the scary message
> >> when using "git commit" to move a detached HEAD from what was checked out
> >> to a new commit.
> >
> > This has been discussed before (I happen to agree with you, but you
> > probably want to address other comments in the thread):
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213
>
> I just re-read the discussion again (thanks for a useful pointers). I
> mostly agree with everything said in the thread and obviously agree with
> its conclusion, but one thing I noticed that everybody (who _was_ a git
> expert) in the thread was assuming bothered me somewhat.
We can of course continue to this public wanking session in our nice
little circle here on git@vger, fully aware that real users will not dare
to interrupt us.
In the alternative, we can go out into the world (you know, that thing
behind the computer screen?) and ask somebody who has _not_ been exposed
to Git for _4 years_ (like most of you!) just how hard it is to work with
Git.
Let me tell you this from my experience: the least likely answer is "the
messages are too scary". Invariably, the answer I get is "it is totally
unintuitive". Often followed by "I tell Git to do something
straight-forward, and it refuses to do it."
Maybe we should just admit that we are no user interface designers, so one
cannot expect miracles from us in that respect. And first and foremost,
we should not pretend to ourselves that we are good at user interfaces,
because we have a track record of sucking in that area. Big time.
Ciao,
Dscho
P.S.: As somebody mentioned already, it is time to fix the tools, not our
users.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 22:46 UTC (permalink / raw)
To: Jeff King
Cc: Daniel Barkalow, Johannes Sixt, Thomas Rast, Johannes Schindelin,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <20091013215751.GA12603@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:
>
>> I personally think that the real issue is that our "detached HEAD" message
>> is still too scary, and what we really want is to issue the scary message
>> when using "git commit" to move a detached HEAD from what was checked out
>> to a new commit. So:
>
> This has been discussed before (I happen to agree with you, but you
> probably want to address other comments in the thread):
>
> http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213
I just re-read the discussion again (thanks for a useful pointers). I
mostly agree with everything said in the thread and obviously agree with
its conclusion, but one thing I noticed that everybody (who _was_ a git
expert) in the thread was assuming bothered me somewhat.
In this sequence:
1$ git checkout $commit_name_that_is_not_a_local_branch
2$ git commit; hack; hack; hack;...
3$ git checkout $branch_name
Step #1 is where the HEAD is detached. It is correct to argue that
detached HEAD is a different state and we should inform unsuspecting
users, which we do.
Step #2 is where a commit that is not connected to any ref is made.
Step #3 is where the state built in the detached HEAD "branch" vanishes
into lost-found.
The experts argued that #3 is where it is dangerous, and while it is
technically correct, an unsuspecting non-expert would not even _know_ that
nothing dangerous is happening while in step #2.
If the commit name used in step #1 were "v1.0.0", and if the user while in
step #2 ran "gitk v1.0.0" (or "git log v1.0.0"), he will be confused by
not seeing the recent commits. The distinction between "detached HEAD"
and being on a branch needs to be understood to appreciate this (and taken
advantage of, when running e.g. "git show-branch v1.0.0 HEAD").
Way before step #3, such a user, even though technically not in any danger
yet, would be confused and panic: "I wanted to fix something in the 1.0.0
release, but where did my fix go?"
The current message in step #1 reads like this:
$ git checkout origin/next
Note: moving to 'origin/next' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 9ecb2a7... Merge branch 'maint'
And perhaps for people who do not understand the second point in the
four-point list [*1*] I showed earlier in the thread, "If you want to
create a new branch" may not be descriptive enough, as a sight-seer and an
occasional typofixer, the user does not know what branch is good for to
begin with, and would not be able to tell if s/he even "wants to create"
one. Perhaps it would help more if we reworded three lines after "Note:"
with something like:
To keep the history of commits you will build from now on in a branch,
you may want to do "git checkout -b <new-branch-name>" now.
and customize the "in a branch" and <new-branch-name> part if the checkout
was given a remote tracking branch and the corresponding local branch does
not yet exist, e.g. in the above example:
To keep the history of commits you will build from now on in 'next'
branch, you may want to do "git checkout -b next" now.
[Footnote]
*1* The world model in which a git user works is:
* You clone and get copies of where the other end has its branches;
* You do all your work on your local branches;
* You may incorporate what the other end further did by merging from the
tracking branch from it;
* You update the other end by pushing what you did on your local branches.
I do not think you can nor should hide them from the user [*2*].
*2* We had to repeat "don't hide but teach" many times until it finally
sank in for another essential thing in the git world model. I hope we do
not have to do the same repeating for the above four points. Luckily we
do not have to repeat "don't hide but teach" about the index anymore these
days.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Björn Steinbrink @ 2009-10-13 22:38 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Johannes Sixt, Thomas Rast, Johannes Schindelin,
Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <alpine.LNX.2.00.0910131654270.32515@iabervon.org>
On 2009.10.13 17:31:46 -0400, Daniel Barkalow wrote:
> The other thing that I think would be nice is:
>
> $ git checkout origin/next
> $ git fetch origin
> $ git checkout !! (probably not a good syntax)
>
> That is, expand "!!" to the string used to detach HEAD, and expand it
> again now. (Of course, something would have to be done if you did "git
> checkout HEAD^1" before, or "git checkout !!^1".) This is related in that
> I think the scary message should happen when "git commit" sees this stored
> string and clears it.
That sounds somewhat like the "git up" hack I've shown here:
http://article.gmane.org/gmane.comp.version-control.git/130050
In #git, Dscho even suggested that "git pull" could do that kind of
DWIMmery while on a detached HEAD that waas reached by checking out a remote
tracking branch. I'm undecided about that, because real merges/rebases
could make it easier to lose work, as opposed to the "fast-forward only"
behaviour I had in mind for that "git up" thing. Though of course, the
"git pull" DWIMmery for a detached HEAD could simply refuse to do
anything but a fast-forward.
Overall, I'm starting to think that improving the "work with a detached
HEAD" area might be more worthwhile than adding DWIMmery that tries to
completely avoid a detached HEAD.
This could include DWIMmery like the "git up"/"git pull" stuff, and
improved security checks, like checking that leaving a detached HEAD
doesn't "lose" any commits to the reflog. So checkout could do
something like "git rev-list HEAD --not --all" (or does --all include
HEAD?) and complain if there's something to be "lost".
Björn
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Eric Raible @ 2009-10-13 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <38cfaa83fdf80dec3a3d81ed3e0de0e2.squirrel@intranet.linagora.com>
Yann Dirson <y.dirson <at> e-sidor.com> writes:
>
> With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
> to a Linux box and committed it.
>
> In that situation, the win32 client in autocrlf mode keeps telling that
> the files are locally modified, even after eg "git reset --hard". Without
> touching the crlf setting (which I believe should not ever be necessary),
> this can be corrected by committing the faulty files after dos2unix'ing
> them, and using "git fetch && git reset --hard origin/master" ("git pull
> --rebase" refuses to do the job since it believes there are local
> changes).
See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
In which Junio suggests:
$ rm .git/index
$ git reset --hard
in order to "restore sanity to your work tree"
^ permalink raw reply
* [PATCH] clone: Supply the right commit hash to post-checkout when -b is used
From: Björn Steinbrink @ 2009-10-13 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ranguvar, Jeff King
When we use -b <branch>, we may checkout something else than what the
remote's HEAD references, but we still used remote_head to supply the
new ref value to the post-checkout hook, which is wrong.
So instead of using remote_head to find the value to be passed to the
post-checkout hook, we have to use our_head_points_at, which is always
correctly setup, even if -b is not used.
This also fixes a segfault when "clone -b <branch>" is used with a
remote repo that doesn't have a valid HEAD, as in such a case
remote_head is NULL, but we still tried to access it.
Reported-by: Devin Cofer <ranguvar@archlinux.us>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
builtin-clone.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 4992c25..5762a6f 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -641,7 +641,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
die("unable to write new index file");
err |= run_hook(NULL, "post-checkout", sha1_to_hex(null_sha1),
- sha1_to_hex(remote_head->old_sha1), "1", NULL);
+ sha1_to_hex(our_head_points_at->old_sha1), "1",
+ NULL);
if (!err && option_recursive)
err = run_command_v_opt(argv_submodule, RUN_GIT_CMD);
--
1.6.5.7.g9ecb2
^ permalink raw reply related
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jeff King @ 2009-10-13 22:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Thomas Rast, Euguess, Mikael Magnusson,
Matthieu Moy, Jay Soffian, git, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0910132302380.4985@pacific.mpi-cbg.de>
On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote:
> So in my opinion, we should DWIM "git checkout $X" to mean "git checkout
> -b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and
> no other refs/remotes/$OTHER/$X.
The similar suggestion that is less magical is to say something like
"there is no $X; maybe you meant $REMOTE/$X?". Is there a reason not to
phase in the behavior, to make sure it is not doing unexpected things?
In other words:
1. In v1.6.6, find all error-correcting candidates and print them as
a suggestion (similar to what we do with "git foo").
2. Then, if we all agree that it seems to be producing sane results,
the next step is to turn the unambiguous cases into a DWIM (and
leave the ambiguous ones with the "did you mean?" message).
Because right now I think there are a lot of hypothetical "maybe it
would be less convenient or more confusing in this instance", but we
don't have any data on how often those instances occur, or how actual
users might react. So doing step (1) would be a way of collecting some
of that data (will users say "stupid git, if you knew what I wanted, why
didn't you just do it?" or "stupid git, your suggestion is just
confusing me!").
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 21:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Thomas Rast, Euguess, Mikael Magnusson, Matthieu Moy, Jeff King,
Jay Soffian, git, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0910132302380.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So in my opinion, we should DWIM "git checkout $X" to mean "git checkout
> -b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and
> no other refs/remotes/$OTHER/$X.
>
> Likewise "git checkout $REMOTE/$X".
>
> But, in my opinion, if there is refs/heads/$X and refs/remotes/origin/$X,
> and the user says "git checkout origin/$X", we should tell the user that
> there are the options to checkout $X and origin/$X^0 (the latter only if
> the user really intended to detach her HEAD), but not try to DWIM
> anything.
I am somewhat unhappy with that kind of inconsistent DWIMery.
Naively I would agree that it would be nice if "git checkout origin/next"
(or "next" when no other remotes/*/next exists) were DWIMmed as "git
checkout -t -b next origin/next". But the way we _define_ that particular
DWIMmery and the way it appears to an uninitiated would be different.
We define this DWIMmery as s|^(.*)/([^/]*)$|-t -b $2 $1/$2|; iow, when the
user types "origin/next" and other coniditions hold, we pretend as if the
user typed "-b next origin/next". But it would give an incorrect
impression to an end user "Ah, when my upstream project has next branch, I
can check it out with origin/next (or next)." But when the user wants to
work further on 'next' by running "git checkout origin/next" the next day,
we say "Uh oh, that is ambiguous and we won't DWIM," which is technically
and implementation wise correct, but breaks the misconception the user
formed with your earlier DWIMmery. I suspect that the user will be better
off if we do not give a wrong impression in the first place. If any
DWIMmery gave a conception different from the following four points, that
DWIMmery is actively hurting the users:
* You clone and get copies of where the other end has its branches;
* You do all your work on your local branches;
* You may incorporate what the other end further did by merging from the
tracking branch from it;
* You update the other end by pushing what you did on your local branches.
Now, the conclusion of the above embodied in the _current_ UI is:
* To start your branch to build on what the other end did, you fork your
local branch at the commit the other end left off, and make sure it builds
on that tracking branch, with
git checkout -t -b next origin/next
* Since "-t -b $2 $1/$2" often appears as a pattern, you can say "-t $1/$2"
and we DWIM as if you said "-t -b $2 $1/$2".
I do not think loosening the DWIMmery so that "$1/$2" is DWIMmed to the
above would help users. If the current DWIM is not helping the users
understand the first four points and instead encouraging an incorrect
picture of how the world works, the new DWIMmery would be just as bad, if
not worse.
> IMHO it is obvious that Hannes' suggestion to fast-forward $X and check it
> out in said scenario has some benefits in certain situations, but dramatic
> downsides in others.
Yes.
> But I need to drive some very important point home in this thread: 1.7.0
> was announced to break some old-time habits in favor of a better
> user-interface. We _need_ to use this opportunity fully.
>
> Even if that means that a few fingers have to be retrained. Because
> retraining a few for the benefit of an easier time with the many others
> is Just Worth It.
Absolutely. My point is that this particular DWIMmery would _NOT_ be a
better user interface. Not for 1.7.0, not for any other release. It
would not help the users to form a clear world model git offers and that
actively hurts them.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jeff King @ 2009-10-13 21:57 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Johannes Sixt, Thomas Rast, Johannes Schindelin,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910131654270.32515@iabervon.org>
On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:
> I personally think that the real issue is that our "detached HEAD" message
> is still too scary, and what we really want is to issue the scary message
> when using "git commit" to move a detached HEAD from what was checked out
> to a new commit. So:
This has been discussed before (I happen to agree with you, but you
probably want to address other comments in the thread):
http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213
-Peff
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Shawn O. Pearce @ 2009-10-13 21:51 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910131732260.32515@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> >
> > For fetch it defaults to "on", but for push I think it defaults
> > to "off".
>
> Nope, on ~line 849 of transport.c, it gets set for all native-transport
> handlers, and never gets turned off. Looks like a misconversion 2 years
> ago defaulting "data->thin" to 1 instead of 0, but it seems not to have
> caused problems.
The rationale for why it was off by default on push was to avoid
making suboptimal packs on the server due to needing to complete
the thin pack out. If its been off for 2 years I guess its not
that big of a deal. We can probably leave thin out then and just
start deprecating the option.
Actually... right now I'm more concerned about why a negotiation
over the native protocol is making the client mention "have v1.5.5"
(yes, the tag object) when I'm trying to fetch between two git.git
repositories that are only 1 Junio work day apart.
In the grand scheme of things over TCP or SSH, that's a few extra
have lines. Over the stateless HTTP its why the final request is
bloating out to 8 KiB worth of have lines. In one Junio work day
we should only be seeing a few hundred new objects, yea pu rewinds,
but v1.5.5 isn't the best common base available to us... IMHO we
shouldn't have even mentioned it.
But fixing this is independent of smart HTTP, I'll try to circle
back later and look at why I'm seeing this oddity in the common
commit negotiation.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Daniel Barkalow @ 2009-10-13 21:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091013205258.GD9261@spearce.org>
On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> > > > > +'option thin'::
> > > > > + Transfer the data as a thin pack if possible.
> > > >
> > > > Does anyone still use non-default thinness?
> > >
> > > Its a command line option on the porcelain.
> >
> > Actually, the command line supports turning it on, and it defaults to on.
> > So I think your helper can safely assume that it's on. :)
>
> For fetch it defaults to "on", but for push I think it defaults
> to "off". Turning it on when pushing on a low bandwidth network
> connection might actually be useful to an end-user.
Nope, on ~line 849 of transport.c, it gets set for all native-transport
handlers, and never gets turned off. Looks like a misconversion 2 years
ago defaulting "data->thin" to 1 instead of 0, but it seems not to have
caused problems.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH v2 05/16] Add multi_ack_2 capability to fetch-pack/upload-pack
From: Shawn O. Pearce @ 2009-10-13 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ocobf067.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > When multi_ack_2 is enabled the ACK continue messages returned by the
> > remote upload-pack are broken out to describe the different states
> > within the peer. This permits the client to better understand the
> > server's in-memory state.
>
> Errr... can't you find better name than multi_ack_2? Perhaps
> multi_ack_detailed or something...
Uh... yes. Good idea. Thanks. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 05/16] Add multi_ack_2 capability to fetch-pack/upload-pack
From: Jakub Narebski @ 2009-10-13 21:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255400715-10508-6-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> When multi_ack_2 is enabled the ACK continue messages returned by the
> remote upload-pack are broken out to describe the different states
> within the peer. This permits the client to better understand the
> server's in-memory state.
Errr... can't you find better name than multi_ack_2? Perhaps
multi_ack_detailed or something...
>
> The fetch-pack/upload-pack protocol now looks like:
[...]
> ACK %s continue
> -----------------------------------
> * multi_ack only:
>
> Sent in response to "have".
>
> The remote side wants the client to consider this object as
> common, and immediately stop transmitting additional "have"
> lines for objects that are reachable from it. The reason
> the client should stop is not given, but is one of the two
> cases below available under multi_ack_2.
>
> ACK %s common
> -----------------------------------
> * multi_ack_2 only:
>
> Sent in response to "have". Both sides have this object.
> Like with "ACK %s continue" above the client should stop
> sending have lines reachable for objects from the argument.
>
> ACK %s ready
> -----------------------------------
> * multi_ack_2 only:
>
> Sent in response to "have".
>
> The client should stop transmitting objects which are reachable
> from the argument, and send "done" soon to get the objects.
>
> If the remote side has the specified object, it should
> first send an "ACK %s common" message prior to sending
> "ACK %s ready".
>
> Clients may still submit additional "have" lines if there are
> more side branches for the client to explore that might be added
> to the common set and reduce the number of objects to transfer.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Questions about the new refs/replace mechanism
From: Jakub Narebski @ 2009-10-13 21:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio, git
In-Reply-To: <4AD31EBF.6090307@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Sergio schrieb:
> > 3) If I remember correctly, there was a reason why grafts were not
> > considered suitable for transferring across repos. Can someone
> > remind me about it? How does the replace mechanism address this
> > issue?
>
> The problem with grafts was that, for example, git-pack-objects obeyed the
> graft, and could create a broken repository by removing grafted-away
> objects. And since git-fsck also obeyed the graft, it did not notice the
> breakage.
To be more detailed, the problem is that if git-pack-objects, git-fsck
and git-gc obeys grafts, it can create broken repository by removing
grafted away objects. If git-pack-objects, git-fsck and git-gc
doesn't obey grafts, it can created broken repository (well, broken if
we include grafts) by removing grafted in objects.
>
> OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> never obey replace entries in the history. But they do keep track of them
> (and the history that they reference) because they are referenced from the
> refs/replace namespace.
In the case of refs/replace git-pack-objects, git-fcsk and git-gc
doesn't "obey" refs/replace... but replaced objects are protected by
pruning by being referenced from refs/replace ref.
One of problems with grafts file was to come up with rule what do do
if both repository you fetch from and the repository you fetch into
have both grafts; in the case of refs/replace the usual rules about
(conflicting) refs apply.
It is also easy to select whether to follow refs/replace or not: you
fetch them into your refs/replace or not; you would have to add extra
option to git-fetch to select whether to fetch and follow grafts in
remote you fetch from.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Daniel Barkalow @ 2009-10-13 21:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Thomas Rast, Johannes Schindelin, Euguess,
Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <7vljjfuibr.fsf@alter.siamese.dyndns.org>
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I suspect that a very common pattern for people who follow trees for
> > testing and such or who only develop in topic branches is:
> > ...
> > << many issues with this kind of DWIM omitted >>
> > ...
> > On the second cycle, either git refuses or does something actively
> > confusing to this user, and the user has to learn the difference between
> > local branches and remote branches on the *second* cycle. IMHO, it's much
> > better to make users learn things at the point when they don't think they
> > know how to use the system, rather than when they think they understand it
> > and are just trying to get things done.
>
> Yeah, and I think J6t pointed out the same issue.
>
> I think it tells us something, after some of "the most trusted Git
> contributors" thought "really long and hard, and making sure to take
> user-friendliness into account at least as much as simplicity of
> implementation", they are getting to the same conclusion that this
> particular DWIMery is a misguided attempt to be helpful without really
> helping but rather hurting the users.
>
> I will stop trying to come up with a strawman for other people's itch that
> I do not agree to begin with, at least for now. I will still look at
> concrete and workable proposals from other people, though.
I personally think that the real issue is that our "detached HEAD" message
is still too scary, and what we really want is to issue the scary message
when using "git commit" to move a detached HEAD from what was checked out
to a new commit. So:
$ git checkout origin/next
(friendly message telling you you're browsing history)
$ git commit
(scary message telling you you're not on any branch)
$ git commit
(one line message like usual, except "detached HEAD" instead of branch
name)
This still makes sure that you get the scary message before you could lose
track of your work, but only gives it to you at the point where there's a
commit that's in your HEAD and nowhere else.
The other thing that I think would be nice is:
$ git checkout origin/next
$ git fetch origin
$ git checkout !! (probably not a good syntax)
That is, expand "!!" to the string used to detach HEAD, and expand it
again now. (Of course, something would have to be done if you did "git
checkout HEAD^1" before, or "git checkout !!^1".) This is related in that
I think the scary message should happen when "git commit" sees this stored
string and clears it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-13 21:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <40aa078e0910131316s308f2bc5h8d679c59c0d5b762@mail.gmail.com>
On Tue, Oct 13, 2009 at 10:16 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> On Tue, Oct 13, 2009 at 9:57 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> This list is sorted. Please keep it so.
> Aha, I didn't notice! Thanks, I'll fix :)
Here's the new (trivial) diff. I don't think it's worth a resend, at
least not yet.
---
diff --git a/Makefile b/Makefile
index fea237b..0d13af3 100644
--- a/Makefile
+++ b/Makefile
@@ -354,6 +354,7 @@ EXTRA_PROGRAMS =
PROGRAMS += $(EXTRA_PROGRAMS)
PROGRAMS += git-fast-import$X
PROGRAMS += git-hash-object$X
+PROGRAMS += git-imap-send$X
PROGRAMS += git-index-pack$X
PROGRAMS += git-merge-index$X
PROGRAMS += git-merge-tree$X
@@ -1075,7 +1076,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
- PROGRAMS += git-imap-send$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
--
Erik "kusma" Faye-Lund
^ permalink raw reply related
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-13 21:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Euguess, Mikael Magnusson, Matthieu Moy, Jeff King,
Jay Soffian, git, Johannes Sixt
In-Reply-To: <7vy6nfwssk.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> [this was probably quoted from Junio, Dscho doesn't have time to go back
> and check, but then, this was not specified in the quoted mail]
>
> >> #2. These are allowed only when unambiguous and there is no local branch yet.
> >>
> >> $ git checkout next ;# ok
> >> $ git checkout frotz ;# ok (origin is not special)
> >> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
> >
> > I'm weakly leaning towards refusing all three, as the user should be
> > required to explicitly say a remote branch should be involved.
> >
> > (Weakly because there's also a certain DWIM advantage to 'git checkout
> > sometopic'...)
>
> I thought this was the primary point of what Dscho has been advocating.
To be honest, I was not advocating anything except being more open to
users' problems, because we _did_ grow a large user base, way beyond the
Linux developers (whom we can always harrass and tell to RTFM).
Just to re-add my well-known stance: consistency is a good thing. So if
things are ambiguous, we can be consistent in saying so and refusing to
DWIM. And if things are _not_ ambiguous, we can be consistent in just
DWIMming what the user most probably meant.
If the user just typed random things in the hope that it works, we cannot
do anything about it anyway.
So in my opinion, we should DWIM "git checkout $X" to mean "git checkout
-b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and
no other refs/remotes/$OTHER/$X.
Likewise "git checkout $REMOTE/$X".
But, in my opinion, if there is refs/heads/$X and refs/remotes/origin/$X,
and the user says "git checkout origin/$X", we should tell the user that
there are the options to checkout $X and origin/$X^0 (the latter only if
the user really intended to detach her HEAD), but not try to DWIM
anything.
IMHO it is obvious that Hannes' suggestion to fast-forward $X and check it
out in said scenario has some benefits in certain situations, but dramatic
downsides in others.
But I need to drive some very important point home in this thread: 1.7.0
was announced to break some old-time habits in favor of a better
user-interface. We _need_ to use this opportunity fully.
Even if that means that a few fingers have to be retrained. Because
retraining a few for the benefit of an easier time with the many others
is Just Worth It.
Or in other words: logic clearly dictates that the needs of the many
outweigh the needs of the few.
Ciao,
Dscho
P.S.: In case certain persons, ahem, think that I am applying the "Many
Outweigh Few" principle to the time involved in top-posting and
"forgetting" to cut quoted text to what is actually addressed: yes, you
could not be more correct. And I no longer believe that this goes without
saying.
^ permalink raw reply
* [PATCH v3] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <200910132206.18460.chriscool@tuxfamily.org>
‘git bisect reset’ accepts an optional argument specifying a branch to
check out after cleaning up the bisection state. This lets you
specify an arbitrary commit.
In particular, this provides a way to clean the bisection state
without moving HEAD: ‘git bisect reset HEAD’. This may be useful if
you are not interested in the state before you began a bisect,
especially if checking out the old commit would be expensive and
invalidate most of your compiled tree.
Clarify the ‘git bisect reset’ documentation to explain this optional
argument, which was previously mentioned only in the usage message.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
Documentation/git-bisect.txt | 23 +++++++++++++++++------
git-bisect.sh | 8 ++++----
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 63e7a42..d2ffae0 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -20,7 +20,7 @@ on the subcommand:
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [(<rev>|<range>)...]
- git bisect reset [<branch>]
+ git bisect reset [<commit>]
git bisect visualize
git bisect replay <logfile>
git bisect log
@@ -81,16 +81,27 @@ will have been left with the first bad kernel revision in "refs/bisect/bad".
Bisect reset
~~~~~~~~~~~~
-To return to the original head after a bisect session, issue the
-following command:
+After a bisect session, to clean up the bisection state and return to
+the original HEAD, issue the following command:
------------------------------------------------
$ git bisect reset
------------------------------------------------
-This resets the tree to the original branch instead of being on the
-bisection commit ("git bisect start" will also do that, as it resets
-the bisection state).
+By default, this will return your tree to the commit that was checked
+out before `git bisect start`. (A new `git bisect start` will also do
+that, as it cleans up the old bisection state.)
+
+With an optional argument, you can return to a different commit
+instead:
+
+------------------------------------------------
+$ git bisect reset <commit>
+------------------------------------------------
+
+For example, `git bisect reset HEAD` will leave you on the current
+bisection commit and avoid switching commits at all, while `git bisect
+reset bisect/bad` will check out the first bad revision.
Bisect visualize
~~~~~~~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index 6f6f039..8b3c585 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -13,8 +13,8 @@ git bisect skip [(<rev>|<range>)...]
mark <rev>... untestable revisions.
git bisect next
find next bisection to test and check it out.
-git bisect reset [<branch>]
- finish bisection search and go back to branch.
+git bisect reset [<commit>]
+ finish bisection search and go back to commit.
git bisect visualize
show bisect status in gitk.
git bisect replay <logfile>
@@ -311,8 +311,8 @@ bisect_reset() {
}
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
- die "$1 does not seem to be a valid branch"
+ 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
+ die "'$1' is not a valid commit"
branch="$1" ;;
*)
usage ;;
--
1.6.5
^ permalink raw reply related
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Junio C Hamano @ 2009-10-13 21:06 UTC (permalink / raw)
To: Michael Wookey
Cc: Johannes Sixt, eduard stefan, Tay Ray Chuan, Git Mailing List,
msysgit
In-Reply-To: <d2e97e800910130443m56ea2850nf72274fc55a4be68@mail.gmail.com>
Michael Wookey <michaelwookey@gmail.com> writes:
> 2009/10/13 Johannes Sixt <j.sixt@viscovery.net>:
>> Michael Wookey schrieb:
>>> Using the above repository, I see the same crash with msysGit at git
>>> revision 1.6.5. Using windbg as the post-mortem debugger, the
>>> following information is captured:
>>> [ ... snip ... ]
>> Wow, this is great work, thank you very much! The function is
>> strip_path_suffix(). And here is a patch that fixes the crash.
>>
>> --- >8 ---
>> From: Johannes Sixt <j6t@kdbg.org>
>> Subject: [PATCH] remote-curl: add missing initialization of argv0_path
>>
>> All programs, in particular also the stand-alone programs (non-builtins)
>> must call git_extract_argv0_path(argv[0]) in order to help builds that
>> derive the installation prefix at runtime, such as the MinGW build.
>> Without this call, the program segfaults (or raises an assertion
>> failure).
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> ---
>> remote-curl.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/remote-curl.c b/remote-curl.c
>> index ad6a163..d8d276a 100644
>> --- a/remote-curl.c
>> +++ b/remote-curl.c
>> @@ -82,6 +82,7 @@ int main(int argc, const char **argv)
>> const char *url;
>> struct walker *walker = NULL;
>>
>> + git_extract_argv0_path(argv[0]);
>> setup_git_directory();
>> if (argc < 2) {
>> fprintf(stderr, "Remote needed\n");
>> --
>> 1.6.5.1024.g31034.dirty
>
> No more crashes for me :)
Beautiful. Thanks, both of you!
^ 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