* 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
* [msysgit? bug] crlf double-conversion on win32
From: Yann Dirson @ 2009-10-13 20:49 UTC (permalink / raw)
To: git
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).
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 20:53 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Sixt, Thomas Rast, Johannes Schindelin, Euguess,
Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910131358000.32515@iabervon.org>
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.
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Shawn O. Pearce @ 2009-10-13 20:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910131550170.32515@iabervon.org>
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.
--
Shawn.
^ permalink raw reply
* Re: Supressing sorting of trees
From: Ealdwulf Wuffinga @ 2009-10-13 20:49 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T182258-9@post.gmane.org>
On Mon, Oct 12, 2009 at 5:51 PM, Sal Mangano
<smangano@into-technology.com> wrote:
> 1) I can write by repository from scratch.
> 2) I can use Git unchanged but preserve order by storing some information in
> each sub tree (e.g. an extra blob) which retains the real order. I can also
> store this information once for the whole "chunks" of the repository.
> 3) I can change Git to suite my needs understanding that it is not Git
> anymore.
>
> For me, (1) makes no sense at this time. I started with the hope that (2)
> would work but realized it is very awkward and will cause performance problems
> because it means most updates where ordering matters will have to update the
> Git trees and my private ordering blob(s). So, after a quick look at the
> source code it seemed like hacking Git into what I wanted was easier than 1
> or 2.
You could add a prefix to the names so you get the order you want. Eg:
a-foo
b-bar
c-baz
If you need to move foo to between bar and baz, you just rename it to
ba-foo, etc.
Ealdwulf
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Daniel Barkalow @ 2009-10-13 20:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091013184531.GB9261@spearce.org>
On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > > diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> > > +'option' <name>::
> > > + This helper supports the option <name> under fetch-multiple.
> > > +
> >
> > I'm a bit surprised that the options only apply in a fetch-multiple
> > section, rather than getting set at the beginning and applying to
> > everything for that run. At least, I think an "option" command should be
> > useable outside of a fetch-multiple (or possible future grouping
> > construct) and have global scope.
>
> In hindsight, I agree with you.
>
> I'll respin the series so the set_option method in the transport
> forwards the options immediately to the helper and lets the helper
> decide whether it accepts or rejects the option string. This will
> clean up the capabilities interface since we no longer need to dump
> the list of options we support in the helper, and as you point out,
> it will make a lot more sense to just set the options for this
> transport instance.
Great. That also makes the "fetch-multiple" start flag no longer
strictly necessary.
> > > REF LIST ATTRIBUTES
> > > -------------------
> > >
> > > @@ -76,10 +80,26 @@ None are defined yet, but the caller must accept any which are supplied.
> > >
> > > FETCH OPTIONS
> > > -------------
> > > +To enable an option the helper must list it in 'capabilities'.
> > >
> > > 'option verbose'::
> > > Print more verbose activity messages to stderr.
> >
> > I think you mis-split the above part; your previoud patch declared this
> > option without declaring any way to use it. Might be worth allowing
> > multiple "verboses" and "quiet" or "option verbosity quiet"/"option
> > verbosity verbose verbose".
>
> Hmmph. "option verbosity verbose verbose" is a bit verbose, don't
> you think? :-)
>
> I think we should just forward the verbosity setting from the
> frontend: "option verbosity [0-n]" where n is the number of
> times -v appeared on the command line/how verbose the user wants.
I think it can go down to -1. Also, I remember needing to have a "-v"
get eaten by the fetch/pull itself, so that you can have fetch/pull tell
you stuff without having the actual protocol interaction getting more
verbose, so it's not exactly the same numbers that get through.
> > > +'option uploadpack' <command>::
> > > + The program to use on the remote side to generate a pack.
> >
> > I sort of feel like the helper ought to read this one out of the config
> > file itself if it wants it.
>
> Eh, true, but you can also set this on the command line. An open
> question I still have for myself is how to set this in HTTP
> transports.
Good point. I doubt people really want to change the executable name for
the same remote between different runs, though.
> The reason why I care is Gerrit Code Review has overloaded the
> 'git-receive-pack' executable and taught it more command line flags:
>
> $ ssh r git receive-pack -h
> git receive-pack PROJECT.git [--cc EMAIL ...] [--help (-h)] [--reviewer (--re) EMAIL ...]
>
> PROJECT.git : project name
> --cc EMAIL : CC user on change(s)
> --help (-h) : display this help text
> --reviewer (--re) EMAIL : request reviewer for change(s)
>
> Which is typically invoked as:
>
> git push --receive-pack "git-receive-pack --reviewer spearce@spearce.org" URL REFSPEC
It seems to me like what we really want is a channel to communicate extra
information to hooks on the server side (or a modified command on the
server). Like:
git push --recv-opt "--reviewer spearce@spearce.org"
or something like that. This would arrange to pass that option to whatever
server-side code is responsible for accepting pushes, without specifying
how it gets there.
> Folks actually have scripts which make this invocation for them, so
> they can insert in the proper reviewer and/or cc arguments. Since
> the arguments vary its hard to set this up in the configuration file.
>
> Over SSH this is fine, we obtain the arguments off the SSH command
> line string and its no big deal. Over git:// this would fail as
> git-daemon can't parse the line anymore. Over HTTP this also is not
> going to work since the service can't receive arbitrary arguements.
>
> My primary motivator for doing smart HTTP now is folks who are
> stuck behind firewalls that permit only HTTP through their local
> proxy servers are unable to communicate with a Gerrit Code Review
> instance over SSH on port 29418. That --reviewer flag above is a
> very useful feature of Gerrit that I somehow have to support for
> the HTTP transport too.
>
> I started down the road of currying this data into the backend by
> at least exposing the option to the helper. How the helper reads
> and uses it is up to the helper.
>
> But given that the value can come in from the command line or from
> the configuration file, I think this should be handled by fetch
> or push porcelain and fed through the helper protocol, and not be
> something that the helper reads from the config directly.
I agree that the porcelain and transport.c should handle "--reviewer
spearce@spearce.org", but I still think they shouldn't handle the
"git-receive-pack" part, and it would probably be easier on everyone if it
was separated in the porcelain, and the native transport knew to stick it
into the receive-pack command line.
> > In general, it would be good to have
> > transport.c and remote.c out of the business of knowing this sort of
> > protocol-specific (albiet specific now to two protocols) information. (Of
> > course, the native protocol's transport methods are in transport.c, so
> > that's there, but I'd like to move that to a transport-native.c someday.)
>
> Agreed, but I have no solution for you due to the --receive-pack
> and --upload-pack arguments supported by the command line git push
> and git fetch/pull porcelain.
>
> But I have been trying to extend the helper interface in a way
> that would allow us to eject the native transport code entirely
> into a helper. We may never bother, there are some advantages to
> being in the push/fetch client process, but I also didn't want to
> get stuck in a corner.
>
> I think with my series we do almost everything we need to support
> native git:// in an external helper process rather than builtin.
> We honor the pack lock file system used by fetch to maintain safe
> concurrent mutations. We use push_refs API and signal back the
> complete information from the remote side. We permit arbitrary
> message strings per ref to be returned by the helper. Etc.
I think it would be a worthwhile exercise to actually write the series to
eject all of the transports into helpers. Then I think we should probably
make the extensions to the helper code this requires, eject the rsync one,
and put bundles and native in contrib instead of using them.
> > > +'option followtags'::
> > > + Aggressively fetch annotated tags if possible.
> >
> > I assume this means to fetch tags which annotate objects we have or are
> > fetching? (As opposed to fetching any annotated tag we could possibly
> > fetch, even if we don't otherwise care about the tag or the thing it
> > tags.) It's obvious in the context of git's config options, but I'd like
> > this document to avoid assuming that context, and the option could apply
> > more generally.
>
> Yes. I'll extend the documentation further in the next iteration.
>
> > > +'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. Until we remove
> the command line flag I think we should still try to honor it
> in implementations that understand that notion.
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. :)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Christian Couder @ 2009-10-13 20:30 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.2.00.0910131605170.5105@dr-wily.mit.edu>
On Tuesday 13 October 2009, Anders Kaseorg wrote:
> On Tue, 13 Oct 2009, Christian Couder wrote:
> > + 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
> > + die "'$1' does not seem to point to a valid commit"
> >
> > It would give a better error message when "git rev-parse" fails instead
> > of:
> >
> > fatal: Needed a single revision
> >
> > and it would not print the SHA1 from "$1^{commit}" when "git rev-parse"
> > succeeds.
>
> Oh, oops, I somehow lost the > /dev/null in my version.
>
> But as for the ‘git rev-parse’ error being confusing, why don’t we fix
> ‘git rev-parse’ instead?
It's a plumbing command, and the output of plumbing commands is not supposed
to change a lot as some scripts may rely on it.
And anyway that would be in another patch.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-13 20:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <200910132159.11616.j6t@kdbg.org>
On Tue, Oct 13, 2009 at 9:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
>> + argv[0] = "/bin/sh";
>> + argv[1] = "-c";
>> + argv[2] = srvc->tunnel;
>> + argv[3] = NULL;
>
> Is there a particular reason that you run "/bin/sh" with a path? I doubt that
> this works on Windows.
>
> -- Hannes
>
It doesn't - I was being conservative. Getting tunneling to work on
Windows hasn't been a part of my priorities (even though I did
briefly test it at some point and got it working, provided a patch
that changed the path to sh to a windows-path). Changing it to "sh -c"
(as was suggested earlier) could AFAIK break something for people who
have other 'sh's in path before /bin -- not that I think it would
matter terribly much.
If I were to fix this, I'd prefer not using sh at all on Windows. I've
seen that connect.c doesn't prepend "/bin/sh -c" at all, requiring
tunnels to be self-contained scripts or native binaries, unless I'm
mistaken. I'm not sure if this works at all on Windows, though. I just
think that the assumption that sh is the shell that is going to run
the tunnel is wrong to make, especially on Windows.
I'm really unsure if it's worth the hassle.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-13 20:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <cb7bb73a0910131241t7220a3c2q16e99a8fc62dd29a@mail.gmail.com>
On Tue, Oct 13, 2009 at 12:41 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
>
> Reproduced, debugged, patch incoming (the problem is not in your patch
> but in esc_param).
>
Thanks. I will test later today. I think a similar problem affects the
branch name labels (the colored boxes with ref names in them) when the
name has utf8 characters.
^ permalink raw reply
* Re: How do I see all of my changes on a branch?
From: Shawn O. Pearce @ 2009-10-13 20:23 UTC (permalink / raw)
To: jonhud; +Cc: git
In-Reply-To: <25879435.post@talk.nabble.com>
jonhud <jon@huddler-inc.com> wrote:
> We are using github (but that's more or less irrelevant, since I'm just
> running git 1.6 locally on Ubuntu). Some time ago, I created a new branch
> (release.2.2) and pushed it out to the remote repository. All the digging
> through log, gitk, etc. has not made it possible for me to figure out the
> commit (or point in time) at which I cut the branch.
git merge-base release2.2 HEAD
Which really lets you do:
git diff $(git merge-base release.2.2 HEAD) HEAD
Which is the long form of:
git diff release-2.2...HEAD
(diff triple dot operator does the merge base computation for you).
--
Shawn.
^ permalink raw reply
* Re: quote in help code example
From: Thomas Rast @ 2009-10-13 20:15 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bill lam, git
In-Reply-To: <20091013153031.GX23777@genesis.frugalware.org>
[-- Attachment #1: Type: Text/Plain, Size: 2721 bytes --]
Miklos Vajna wrote:
> On Tue, Oct 13, 2009 at 10:06:23PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > 2. now the .ft pair fixed but it still displayed incorrect quote.
> >
> > git filter-branch --tree-filter ´rm filename´ HEAD
> >
> > it should be 'rm filename' not ´rm filename´
>
> I can reproduce that here as well, that's how it is in the official
> manpages as well (see the man branch), so that's not specific to your
> system.
Same here. The patch below is a band-aid fix that works for me, but
I'd rather have it tested on various docbook/asciidoc combinations if
anyone still runs them.
My findings so far were that asciidoc correctly turns the apostrophe
into an ' entity in the .xml output, and xmlto then turns it into
\' instead of just ' in the troff output. Then, if the terminal
appears to support Unicode (this can be disabled with LC_ALL=C or
such) the formatter turns it into a "real" apostrophe that, of course,
is not understood by any ASCII-based tool.
So far so good, and sounded like an easy debugging job, right? Not
so. The buzzword-compliance people apparently felt it would be nice
to wrap a bad joke of a language in the bad joke of a language that
XML already is, and thus was XSL invented. Deep in the horrors of
these XSL files, in my case in
/usr/share/xml/docbook/stylesheet/nwalsh/1.75.2/manpages/other.xsl
there's a template that, according to the comment near it, maltreats
our apostrophes:
* The backslash, dot, dash, and apostrophe (\, ., -, ') characters
* have special meaning for roff, so before we do any other
* processing, we must escape those characters where they appear in
* the source content.
The patch below just replaces said template with a no-op for git's
manpage creation. I have not been able to substantiate the claim that
apostrophes are special, and in fact with the patch my manpages look
fine. Then again I don't know anything about roff syntax either, and
manuals seem a bit hard to come by.
Grrr.
diff --git i/Documentation/manpage-base.xsl w/Documentation/manpage-base.xsl
index a264fa6..7c14469 100644
--- i/Documentation/manpage-base.xsl
+++ w/Documentation/manpage-base.xsl
@@ -7,6 +7,11 @@
<xsl:param name="man.output.quietly" select="1"/>
<xsl:param name="refentry.meta.get.quietly" select="1"/>
+<xsl:template name="escape.apostrophe">
+ <xsl:param name="content"/>
+ <xsl:value-of select="$content"/>
+</xsl:template>
+
<!-- convert asciidoc callouts to man page format;
git.docbook.backslash and git.docbook.dot params
must be supplied by another XSL file or other means -->
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox