* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Johannes Schindelin @ 2008-06-24 14:55 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080624144254.GG5528@leksak.fem-net>
Hi,
On Tue, 24 Jun 2008, Stephan Beyer wrote:
> > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
>
> Are they intentionally undocumented to not raise confusion?
Umm. Which part of "TOY" is unclear?
Ciao,
Dscho
^ permalink raw reply
* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Nicolas Pitre @ 2008-06-24 15:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0806241515460.9925@racer>
On Tue, 24 Jun 2008, Johannes Schindelin wrote:
>
> When you look for a fix instead of a regression, it can be quite hard
> to twist your brain into choosing the correct bisect command between
> 'git bisect bad' and 'git bisect good'.
>
> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
I really like it. And yes, I know what you mean.
Nicolas
^ permalink raw reply
* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Stephan Beyer @ 2008-06-24 15:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0806241555300.9925@racer>
> > > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
> >
> > Are they intentionally undocumented to not raise confusion?
>
> Umm. Which part of "TOY" is unclear?
The T, O and Y.
No; after searching for "TOY PATCH" on gmane: none :)
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] clone: create intermediate directories of destination repo
From: Daniel Barkalow @ 2008-06-24 15:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Brandon Casey, zuh, git
In-Reply-To: <20080624080437.GA2581@sigill.intra.peff.net>
On Tue, 24 Jun 2008, Jeff King wrote:
> On Tue, Jun 24, 2008 at 12:39:40AM -0700, Junio C Hamano wrote:
>
> > > The shell version used to use "mkdir -p" to create the repo path, but
> > > the C version just calls "mkdir". Let's replicate the old behavior. In
> > > this case we can simply create the directories leading up to the git
> > > dir. If it's a bare repo, then that is everything that init_db wants
> > > ahead of time. If it isn't bare, then the worktree contains the git dir,
> > > so we create the worktree.
> >
> > Clever ;-)
>
> I am worried that it is too clever. I didn't see an obvious way for
> work_tree and git_dir to not have that property, but I think it is still
> worth somebody double-checking.
I think you can specify git_dir and work_tree on the command line, and set
them to whatever you want, although I now don't remember whether they're
actually both followed for clone (I tried to match the shell version,
whose behavior didn't make too much sense to me).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Brandon Casey @ 2008-06-24 15:29 UTC (permalink / raw)
To: David Jeske; +Cc: git
In-Reply-To: <willow-jeske-01l5oJ=64=91FEDjCgQT>
David Jeske wrote:
> As a more practical question, how do I do this workflow illustrated below?
>
> It's sort of similar to the workflow that "git stash" is trying to support,
> except that I have a bunch of commits instead of a bunch of
> uncommitted-changes.
>
> I pull a repository that looks like this:
>
> . a<--b<--c <--master
git clone <master_repo>
cd master_repo
>
> Then I hack away to this, and then throw my own branch on the end, along with
> master:
>
> . a<--b<--c<--d<--e<--f<--g <--master (jeske)
> . <--feature1 (jeske)
hack hack hack
git commit -a -m 'd'
hack hack hack
git commit -a -m 'e'
hack hack hack
git commit -a -m 'f'
hack hack hack
git commit -a -m 'g'
git branch feature1
>
> While the server looks like this:
>
> . a<--b<--c<--1<--2<--3 <--master (server)
git fetch
> I want to get my repository to look something like this:
>
> . a<--b<--c<--1<--2<--3 <--master (jeske)
> . \
> . d<--e<--f<--g <-- feature1 (jeske)
git reset --hard origin/master
Side Note: you probably should have been developing on 'feature1' branch
from the start. 'reset --hard' is a special case. If feature1 is a private
branch for developing in, you may want to rebase it ontop of master and retest
before merging into master and pushing so that you can maintain a nice linear
history when possible. Or you can just merge into master and then push.
> So I can then do this:
>
> . a<--b<--c<--1<--2<--3<--zz <--master (jeske)
> . \
> . d<--e<--f<--g <-- feature1 (jeske)
hack hack hack
git commit -a -m 'zz'
>
> ..and then push zz onto the server after 3.
git push
> ..and I want to do it with safe commands that won't leave any dangling
> references. (say if I forget to put the feature1 branch on)
_Don't_ forget. 'reset --hard' is named that way for a reason. If you do
forget, git makes it _easy_ to recover from.
Let's say you _did_ forget. You did the 'reset --hard' on master and then
you committed the 'zz' change without creating the 'feature1' branch.
You can still create the feature1 branch since git saved the previous state
in the reflog. It is two changes back.
git branch feature1 master@{2}
If you didn't know it was two changes back, then you can look through the
reflog using 'git log -g master'. The commit message is there along with a
reflog message describing what action was performed.
After saying all of that, here is how I think you _should_ have done things.
Notice I _did_not_ use 'reset --hard'.
git clone <master_repo>
cd master_repo
git checkout -b feature1 # we create our feature branch immediately since
# creating branches is so effortless in git. A
# private feature branch should _always_ be created
# and used for development.
hack hack hack
git commit -a -m 'd' # Make our 4 commits on the feature branch
hack hack hack
git commit -a -m 'e'
hack hack hack
git commit -a -m 'f'
hack hack hack
git commit -a -m 'g'
git checkout master # Let's go back to master
git pull # Fetch and merge the changes from the server
git checkout -b 'master_zz' # Create a branch for developing the zz feature
hack hack hack
git commit -a -m 'zz' # Commit the zz feature
git checkout master # Go back to master
git merge master_zz # Merge zz
git push # And push master out
git branch -d master_zz # Now we're done with master_zz since it's all merged in
Now you're in the same place you were above, you can continue developing your feature
on feature1 branch by checking it out. This is also were rebase comes in handy, since
you may want to rebase feature1 on top of the new current master. Once it is done and
retested, you merge it into master and push it out.
-brandon
^ permalink raw reply
* Re: [PATCH/RFC] Created git-basis and modified git-bundle to accept --stdin.
From: Adam Brewster @ 2008-06-24 15:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3iqvzl091.fsf@localhost.localdomain>
>> Git-basis is a perl script that remembers bases for use by git-bundle.
>> Code from rev-parse was borrowed to allow git-bundle to handle --stdin.
>
> I'd rather you follow git-pack-objects, and use `--revs` for the name
> of this option (or even '--not --revs'). The name `--stdin` might
> imply that you are providing objects names on stdin of git-bundle.
>
> But perhaps I am worrying over nothing.
>
This seems like a fine idea.
> [...]
>> Then you can add the objects in the bundle to the basis, so they won't
>> get included in the next pack like this:
>>
>> $ git-basis --update my-basis < my-bundle
>
> Why not use "$(git ls-remote my-bundle)" somewhere in the invocation
> creating new bundle instead?
>
You could use "git ls-remote my-bundle | git-basis --update my-basis"
to do the same thing as the command I gave above.
>> I'm sure that my implementation is crap, but I think this is a useful
>> idea. Anybody agree? Disagree?
>
> Documentation, please? Especially that it looks like '--stdin' option
> is a bit tricky...
>
I wanted to test the waters and make sure that someone was at least
vaguely interested in this (no need to document code that is never
going to leave my machine).
I'll prepare another patch with documentation and changing --stdin to
--revs when I get a chance.
Thank you,
Adam Brewster
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Klas Lindberg @ 2008-06-24 15:31 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8aa486160806240727r6fc6de6doec8300700293a3a7@mail.gmail.com>
>>> git branch -a
>>>
>
> empty?
Sorry, my mistake. It lists "master"
>>> git-pull bogustree refs/tags/foo_tag:refs/heads/b
>>
>> actually does update branch "b". I find the behaviour quite inconsistent.
>
> You asked explicitly to update branch b with :refs/heads/b.
I'm not sure what you mean. I asked it to update local branch "b"
against remote tag "foo_tag" and it did just that. I find it
inconsistent that pull can do this, but fetch can't.
> Can you explain why you have to do it this way? Or the whole workflow?
I am looking into the possibility of writing a tool that handles
configurations of trees. For instance, I want the tool to be able to
consume some version of a configuration and create, update or reset
branches in other trees accordingly.
The main stumbling block is actually that a lot of git commands have
side effects on the working tree (usually because they do something
with a "current" branch). In my mind, the user should be able to
select a configuration that effectively fast forwards branches in some
trees and resets branches in others -- all of it without touching any
working trees (unless there is an explicit checkout).
The example in this case is that fetching tags to update a branch
isn't possible. Pulling *is* possible, but would also update the
current branch and the working tree.
/Klas
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Klas Lindberg @ 2008-06-24 15:36 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <33f4f4d70806240831q14caacddp66645e1bcfb6d14b@mail.gmail.com>
> I'm not sure what you mean. I asked it to update local branch "b"
> against remote tag "foo_tag" and it did just that. I find it
> inconsistent that pull can do this, but fetch can't.
I'm sorry. That was plain wrong. It doesn't update the branch from the
remote tag when I pull.
Oh well...
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-06-24 16:02 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Junio C Hamano, git
In-Reply-To: <9B8F0B10-F48D-475B-BF59-CEE94222B6E8@ai.rug.nl>
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> Vienna:bin pieter$ git --version
> git version 1.5.6.129.g274ea
> Vienna:bin pieter$ git clone localhost:project/bonnenteller
> Initialize bonnenteller/.git
> Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> Password:
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
>
> I think that is what Miklos meant.
Exactly. Thanks for the good description.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] git-svn docs: mention svn.addAuthorFrom and svn.useLogAuthor config options.
From: Avery Pennarun @ 2008-06-24 16:02 UTC (permalink / raw)
To: git, gitster; +Cc: Avery Pennarun
In-Reply-To: <20080624073707.GA6495@frsk.net>
At least one person got confused because they thought it was necessary to
provide these on the command line every time.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
---
Documentation/git-svn.txt | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 97bed54..e8200ce 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -64,13 +64,16 @@ COMMANDS
--use-log-author;;
When retrieving svn commits into git (as part of fetch, rebase, or
dcommit operations), look for the first From: or Signed-off-by: line
- in the log message and use that as the author string.
+ in the log message and use that as the author string. (To enable
+ this permanently, use git config svn.useLogAuthor)
--add-author-from;;
When committing to svn from git (as part of commit or dcommit
operations), if the existing log message doesn't already have a
From: or Signed-off-by: line, append a From: line based on the
- git commit's author string. If you use this, then --use-log-author
- will retrieve a valid author string for all commits.
+ git commit's author string. If you use this, then if you enable
+ --use-log-author it will retrieve a valid author string for all
+ commits. (To enable this option permanently, use git config
+ svn.addAuthorFrom)
--username=<USER>;;
For transports that SVN handles authentication for (http,
https, and plain svn), specify the username. For other
--
1.5.6.56.g29b0d
^ permalink raw reply related
* [PATCH/RFC] git-svn: sanitize_remote_name should accept underscores.
From: Avery Pennarun @ 2008-06-24 15:54 UTC (permalink / raw)
To: git, normalperson, gitster; +Cc: Avery Pennarun
Without this patch, git-svn failed with the error:
config --get svn-remote.D2007.Win32.url: command returned error: 1
...upon trying to automatically follow a link from a child branch back to
its parent branch D2007_Win32 (note the underscore, not dot, separating the
two words).
Note that I have each of my branches defined (by hand) as separate
svn-remote entries in .git/config since my svn repository layout is
nonstandard.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
---
I'm not sure why sanitize_remote_name is so picky about allowed characters,
but underscore should certainly be allowed. I'm worried that this has
revealed a more serious problem, since presumably sanitizing the name
shouldn't break anything in any case.
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4c9c59b..263d66c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1465,7 +1465,7 @@ sub verify_remotes_sanity {
# we allow more chars than remotes2config.sh...
sub sanitize_remote_name {
my ($name) = @_;
- $name =~ tr{A-Za-z0-9:,/+-}{.}c;
+ $name =~ tr{A-Za-z0-9:,_/+-}{.}c;
$name;
}
--
1.5.6.56.g29b0d
^ permalink raw reply related
* Re: git-fetch remote tag to local branch fails
From: Santi Béjar @ 2008-06-24 16:11 UTC (permalink / raw)
To: Klas Lindberg; +Cc: git
In-Reply-To: <33f4f4d70806240831q14caacddp66645e1bcfb6d14b@mail.gmail.com>
On Tue, Jun 24, 2008 at 17:31, Klas Lindberg <klas.lindberg@gmail.com> wrote:
>
>> Can you explain why you have to do it this way? Or the whole workflow?
>
> I am looking into the possibility of writing a tool that handles
> configurations of trees.
Maybe you should be using the plumbing commands.
> For instance, I want the tool to be able to
> consume some version of a configuration and create, update or reset
> branches in other trees accordingly.
What are the "other trees"?
Do you mean this?
1. You have a repository with different branches as:
master
tree1
tree2
..
2. You want /path/to/tree1 to always checkout tree1
and the same for treeN
Then
3. In /path/to/treeN/.. you do:
$ git clone /path/to/repo treeN
$ git checkout -b treeN origin/treeN
4. To keep uptodate:
$ git pull
5. The branches for the other trees are always uptodate in origin/*.
> The main stumbling block is actually that a lot of git commands have
> side effects on the working tree (usually because they do something
> with a "current" branch).
Sure. So you have to choose those that don't have these "side
effects", you have plenty of them, mainly in the low-level, plumbing
commands.
> In my mind, the user should be able to
> select a configuration that effectively fast forwards branches in some
> trees and resets branches in others -- all of it without touching any
> working trees (unless there is an explicit checkout).
Well, if you touch the current branch, for sure, you want to update
the working tree.
Maybe you want to keep your local branches up to date with respect
their tracking branch?
> The example in this case is that fetching tags to update a branch
> isn't possible.
I don't see the point updating a branch with a tag, but you can make a
tool to update a branch with a tag, see for example
contrib/examples/git-fetch.sh.
Santi
^ permalink raw reply
* [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Christian Holtje @ 2008-06-24 16:23 UTC (permalink / raw)
To: git; +Cc: gitster
When commit files that use DOS style CRLF end-of-lines, the pre-commit
hook would raise an error. When combined with the fact that the hooks
get activated by default on windows, it makes life difficult for
people working with DOS files.
This patch causes the pre-commit hook to deal with crlf files
correctly.
Signed-off-by: Christian Höltje <docwhat@gmail.com>
---
t/t7503-template-hook--pre-commit.sh | 75 +++++++++++++++++++++++++
+++++++++
templates/hooks--pre-commit | 10 ++++-
2 files changed, 83 insertions(+), 2 deletions(-)
create mode 100755 t/t7503-template-hook--pre-commit.sh
diff --git a/t/t7503-template-hook--pre-commit.sh b/t/t7503-template-
hook--pre-commit.sh
new file mode 100755
index 0000000..8f0c3c9
--- /dev/null
+++ b/t/t7503-template-hook--pre-commit.sh
@@ -0,0 +1,75 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Christian Höltje
+#
+
+test_description='t7503 templates-hooks--pre-commit
+
+This test verifies that the pre-commit hook shipped with
+git by default works correctly.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'verify that autocrlf is unset' '
+ if git config core.autocrlf
+ then
+ false
+ else
+ test $? -eq 1
+ fi
+'
+
+test_expect_success 'lf without hook' '
+
+ echo "foo" > lf.txt &&
+ git add lf.txt &&
+ git commit -m "lf without hook" lf.txt
+
+'
+
+test_expect_success 'crlf without hook' '
+
+ echo "foo\r" > crlf.txt &&
+ git add crlf.txt &&
+ git commit -m "crlf without hook" crlf.txt
+
+'
+
+# Set up the pre-commit hook.
+HOOKDIR="$(git rev-parse --git-dir)/hooks"
+mkdir -p "${HOOKDIR}"
+cp -r "${HOOKDIR}-disabled/pre-commit" "${HOOKDIR}/pre-commit"
+chmod +x "${HOOKDIR}/pre-commit"
+
+test_expect_success 'lf with hook' '
+
+ echo "bar" >> lf.txt &&
+ git add lf.txt &&
+ git commit -m "lf with hook" lf.txt
+
+'
+test_expect_success 'crlf with hook' '
+
+ echo "bar\r" >> crlf.txt &&
+ git add crlf.txt &&
+ git commit -m "crlf with hook" crlf.txt
+
+'
+
+test_expect_success 'lf with hook white-space failure' '
+
+ echo "bar " >> lf.txt &&
+ git add lf.txt &&
+ ! git commit -m "lf with hook" lf.txt
+
+'
+test_expect_success 'crlf with hook white-space failure' '
+
+ echo "bar \r" >> crlf.txt &&
+ git add crlf.txt &&
+ ! git commit -m "crlf with hook" crlf.txt
+
+'
+
+test_done
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index b25dce6..335ca09 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -55,8 +55,14 @@ perl -e '
if (s/^\+//) {
$lineno++;
chomp;
- if (/\s$/) {
- bad_line("trailing whitespace", $_);
+ if (/\r$/) {
+ if (/\s\r$/) {
+ bad_line("trailing whitespace", $_);
+ }
+ } else {
+ if (/\s$/) {
+ bad_line("trailing whitespace", $_);
+ }
}
if (/^\s* \t/) {
bad_line("indent SP followed by a TAB", $_);
--
1.5.5.4
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-06-24 16:25 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Pieter de Bie, Junio C Hamano, git
In-Reply-To: <20080624160224.GA29404@genesis.frugalware.org>
Hi,
On Tue, 24 Jun 2008, Miklos Vajna wrote:
> On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > Vienna:bin pieter$ git --version
> > git version 1.5.6.129.g274ea
> > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > Initialize bonnenteller/.git
> > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > Password:
> > bash: git-upload-pack: command not found
> > fatal: The remote end hung up unexpectedly
> >
> > I think that is what Miklos meant.
>
> Exactly. Thanks for the good description.
AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into
next).
Ciao,
Dscho
^ permalink raw reply
* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Jeff King @ 2008-06-24 16:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0806241515460.9925@racer>
On Tue, Jun 24, 2008 at 03:17:18PM +0100, Johannes Schindelin wrote:
> When you look for a fix instead of a regression, it can be quite hard
> to twist your brain into choosing the correct bisect command between
> 'git bisect bad' and 'git bisect good'.
>
> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
Thanks. This just bit me the other day, and I thought of the same
solution. I think it might be worth a "non-toy" patch.
-Peff
^ permalink raw reply
* Re: Segmentation fault on http clone, post-1.5.6
From: Jeff King @ 2008-06-24 16:40 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <20080624130457.GB13696@mithlond.arda.local>
On Tue, Jun 24, 2008 at 04:04:57PM +0300, Teemu Likonen wrote:
> With the current "master" branch version (29b0d0191) I get segmentation
> fault when trying to clone a git repo with http protocol. Tried a couple
> of times and it's always reproducible. You can test with the following
> repository (about 5.5 MB):
>
> git clone http://www.iki.fi/tlikonen/voikko.git
I can't reproduce the segfault here.
> I also build git from the tag v1.5.6 and it seems to work fine, so
> I guess the bug was introduced after 1.5.6.
That sounds like an excellent opportunity to learn about git-bisect. Can
you try bisecting the bug and reporting back the problematic commit?
-Peff
^ permalink raw reply
* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Johannes Schindelin @ 2008-06-24 16:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080624163810.GA4654@sigill.intra.peff.net>
Hi,
On Tue, 24 Jun 2008, Jeff King wrote:
> On Tue, Jun 24, 2008 at 03:17:18PM +0100, Johannes Schindelin wrote:
>
> > When you look for a fix instead of a regression, it can be quite hard
> > to twist your brain into choosing the correct bisect command between
> > 'git bisect bad' and 'git bisect good'.
> >
> > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
>
> Thanks. This just bit me the other day, and I thought of the same
> solution. I think it might be worth a "non-toy" patch.
Okay, that's 3 people who I take the courage from to turn this into a
proper patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Reini Urban @ 2008-06-24 16:54 UTC (permalink / raw)
To: git
In-Reply-To: <20080624163810.GA4654@sigill.intra.peff.net>
Jeff King schrieb:
> On Tue, Jun 24, 2008 at 03:17:18PM +0100, Johannes Schindelin wrote:
>
>> When you look for a fix instead of a regression, it can be quite hard
>> to twist your brain into choosing the correct bisect command between
>> 'git bisect bad' and 'git bisect good'.
>>
>> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
>
> Thanks. This just bit me the other day, and I thought of the same
> solution. I think it might be worth a "non-toy" patch.
Maybe "notfixed" is a better wording than "unfixed".
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Linus Torvalds @ 2008-06-24 16:59 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Pierre Habouzit, Git Mailing List,
Junio C Hamano
In-Reply-To: <20080624053504.GB19224@sigill.intra.peff.net>
On Tue, 24 Jun 2008, Jeff King wrote:
>
> You seem to have a bunch of _other_ problems with parse_options. And
> that is fine, but they have nothing whatsoever to do with anything I've
> said. So don't "sky wizard" _me_ about those problems. ;P
I have a _single_ problem I have with parse_options(), namely that it was
painful to convert in pieces. It may well be that builtin-blame.c was one
of the more painful cases, but it really was a _single_ issue.
I also had a _single_ fix for it.
I never had "other" problems.
What happened was that you and Dscho and others then tried to pick that
_single_ issue apart, because the solutions _you_ wanted (tying all the
parsing together in one place) couldn't handle it as one issue and one
problem. Your solutions always looked at just some small part of it.
So no, I never introduced any other problems in the discussion at all. I
had a single issue, and a single solution. You were the one who then
argued against it and had *another* solution that fractured the problem
up, and didn't actually solve _any_ of my original issues.
Do you see now?
So yes, we're arguing at cross purposes, but that's because you're
constantly taking up a totally different and totally uninteresting
position that has nothing what-so-ever to do with the original problem.
And then you talk about how things "ought to be" in your world, to make
your solution relevant at all.
And I'm trying to tell you that "ought to be" has no relevance, because
you're not even looking at the problem!
Linus
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Linus Torvalds @ 2008-06-24 17:05 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Git Mailing List
In-Reply-To: <20080624082447.GB24357@artemis.madism.org>
On Tue, 24 Jun 2008, Pierre Habouzit wrote:
>
> Actually this doesn't work because it may point into the strbuf that
> will be invalidated later. Our sole option here is to leak some memory I
> fear.
I think leaking memory is ok (it's obviously going to be bounded by the
size of the arguments you pass into a program), but I also think you can
just change the option strings in place.
Yeah, I know - it's impolite, and we even marked things "const char", but
"const" in C is just a politeness thing, we can just choose to have a
function with a big comment that changes the string anyway. We'll have to
make sure that the few places that actually create argument strings by
hand (ie not from the ones supplied by a real "execve()") not do them so
that they need splitting (but no current ones would need to, obviously,
since splitting the argumens isn't even supported yet).
Or, if people hate that, just leak a few malloc'ed areas. That's arguably
the more straightforward way.
Linus
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Daniel Barkalow @ 2008-06-24 17:10 UTC (permalink / raw)
To: Erez Zilber; +Cc: Robert Haines, Matthias Kestenholz, git
In-Reply-To: <ce513bcc0806240745l365b2d22ga007deb01a93e4b6@mail.gmail.com>
On Tue, 24 Jun 2008, Erez Zilber wrote:
> BTW - I'm currently running git-daemon in the following way:
>
> sudo git-daemon --base-path=/pub/git/ --export-all
>
> Is there any advantage to run it through xinetd? How do you run it?
You probably want to run it from something that init runs, or you'll have
to figure it out again when you reboot the server in a while. So you
either want a suitable init script (Gentoo, for example, has one in their
git package), or to run it through xinetd (which you almost certainly have
an init script for).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Johannes Schindelin @ 2008-06-24 17:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0806241750030.9925@racer>
When you look for a fix instead of a regression, it can be quite hard
to twist your brain into choosing the correct bisect command between
'git bisect bad' and 'git bisect good'.
So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 24 Jun 2008, Johannes Schindelin wrote:
> Okay, that's 3 people who I take the courage from to turn this
> into a proper patch.
And this is my first attempt at a proper patch for it.
Now with documentation, and hopefully all places where the
user is being told about a "bad" commit.
Documentation/git-bisect.txt | 16 ++++++++++++++++
git-bisect.sh | 25 ++++++++++++++++++-------
2 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 3ca0d33..3fb3b11 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -26,6 +26,9 @@ on the subcommand:
git bisect log
git bisect run <cmd>...
+ git bisect fixed [<rev>]
+ git bisect unfixed [<rev>...]
+
This command uses 'git-rev-list --bisect' option to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
@@ -76,6 +79,19 @@ bad", and ask for the next bisection.
Until you have no more left, and you'll have been left with the first
bad kernel rev in "refs/bisect/bad".
+Searching for fixes instead of regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes you need to find a fix, not a regression. The bisection
+machinery is really the same for this, but it might be tricky to remember
+to mark a commit "bad" when it contains the fix.
+
+So synonyms for "bad" and "good" are available, "fixed" and "unfixed"
+respectively.
+
+To mark a commit that contains the fix, call "git bisect fixed", and
+"git bisect unfixed" if it does not contain the fix.
+
Bisect reset
~~~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index 8b11107..6e71e1a 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|fixed|unfixed|skip|next|reset|visualize|replay|log|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
@@ -24,6 +24,13 @@ git bisect log
git bisect run <cmd>...
use <cmd>... to automatically bisect.
+When not looking for a regression, but a fix instead, you can use
+
+git bisect fixed [<rev>]
+ mark <rev> as having the fix you are looking for
+git bisect unfixed [<rev>]
+ mark <rev> as not having the fix you are looking for
+
Please use "git help bisect" to get the full man page.'
OPTIONS_SPEC=
@@ -216,7 +223,7 @@ bisect_next_check() {
t,,good)
# have bad but not good. we could bisect although
# this is less optimum.
- echo >&2 'Warning: bisecting only with a bad commit.'
+ echo >&2 'Warning: bisecting only with a bad (or fixed) commit.'
if test -t 0
then
printf >&2 'Are you sure [Y/n]? '
@@ -231,7 +238,7 @@ bisect_next_check() {
THEN='then '
}
echo >&2 'You '$THEN'need to give me at least one good' \
- 'and one bad revisions.'
+ 'and one bad (or fixed) revision.'
echo >&2 '(You can use "git bisect bad" and' \
'"git bisect good" for that.)'
exit 1 ;;
@@ -324,7 +331,7 @@ exit_if_skipped_commits () {
_tried=$1
if expr "$_tried" : ".*[|].*" > /dev/null ; then
echo "There are only 'skip'ped commit left to test."
- echo "The first bad commit could be any of:"
+ echo "The first bad (or fixed) commit could be any of:"
echo "$_tried" | tr '[|]' '[\012]'
echo "We cannot bisect more!"
exit 2
@@ -356,7 +363,7 @@ bisect_next() {
fi
if [ "$bisect_rev" = "$bad" ]; then
exit_if_skipped_commits "$bisect_tried"
- echo "$bisect_rev is first bad commit"
+ echo "$bisect_rev is first bad (or fixed) commit"
git diff-tree --pretty $bisect_rev
exit 0
fi
@@ -474,7 +481,8 @@ bisect_run () {
cat "$GIT_DIR/BISECT_RUN"
- if grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
+ if grep "first bad (or fixed) commit could be any of" \
+ "$GIT_DIR/BISECT_RUN" \
> /dev/null; then
echo >&2 "bisect run cannot continue any more"
exit $res
@@ -486,7 +494,8 @@ bisect_run () {
exit $res
fi
- if grep "is first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
+ if grep "is first bad (or fixed) commit" \
+ "$GIT_DIR/BISECT_RUN" > /dev/null; then
echo "bisect run success"
exit 0;
fi
@@ -501,6 +510,8 @@ case "$#" in
*)
cmd="$1"
shift
+ test $cmd = fixed && cmd=bad
+ test $cmd = unfixed && cmd=good
case "$cmd" in
help)
git bisect -h ;;
--
1.5.6.173.gde14c
^ permalink raw reply related
* Re: why is git destructive by default? (i suggest it not be!)
From: Boaz Harrosh @ 2008-06-24 17:11 UTC (permalink / raw)
To: David Jeske; +Cc: git
In-Reply-To: <willow-jeske-01l5cKsCFEDjC=91MX>
David Jeske wrote:
> As a new user, I'm finding git difficult to trust, because there are operations
> which are destructive by default and capable of inadvertently throwing hours or
> days of work into the bit bucket.
>
> More problematic, those commands have no discernible pattern that shows their
> danger, and they need to be used to do typical everyday things. I'm starting to
> feel like I need to use another source control system on top of the git
> repository in case I make a mistake. My philosophy is simple, I never never
> never want to throw away changes, you shouldn't either. Disks are cheaper than
> programmer hours. I can understand wanting to keep things tidy, so I can
> understand ways to correct the 'easily visible changes', and also avoid pushing
> them to other trees, but I don't understand why git needs to delete things.
>
> For example, the following commands seem capable of totally destroying hours or
> days of work. Some of them need to be used regularly to do everyday things, and
> there is no pattern among them spelling out danger.
>
> git reset --hard : if another branch name hasn't been created
git reset --hard is special see below
> git rebase
> git branch -D <branch> : if branch hasn't been merged
> git branch -f <new> : if new exists and hasn't been merged
> git branch -m <old> <new> : if new exists and hasn't been merged
>
The rest of the commands are recoverable from the log as people said
but "git reset --hard" is not and should be *fixed*!
I use git reset --hard in to separate and distinct functions.
One - to move current branch head around from place to place.
Two - Throw away work I've edited
It has happened to me more then once that I wanted the first
and also got the second as an un-warned bonus, to the dismay
of my bosses. (What do I care if I need to write all this code
again)
I would like git-reset --hard to refuse if a git-diff HEAD
(both staged and unstaged) is not empty. with a -f / -n logic
like git-clean. (like git-clean none default config file override)
Now I know that the first usage above could be done with
git-branch -f that_branch the_other_branch. But that can
not be preformed on the current branch and local changes
are not lost.
Lots of other potentially destructive git-commands check for local
changes and refuse to operate. To remedy them git-reset --hard
is recommended. I would prefer if there was a git-reset --clean -f/-n
for the first case and git reset --hard only for the second usage
case.
My $0.017
Boaz
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Johannes Schindelin @ 2008-06-24 17:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, Pierre Habouzit, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.1.10.0806240954150.2926@woody.linux-foundation.org>
Hi,
On Tue, 24 Jun 2008, Linus Torvalds wrote:
> On Tue, 24 Jun 2008, Jeff King wrote:
> >
> > You seem to have a bunch of _other_ problems with parse_options. And
> > that is fine, but they have nothing whatsoever to do with anything
> > I've said. So don't "sky wizard" _me_ about those problems. ;P
>
> I have a _single_ problem I have with parse_options(), namely that it was
> painful to convert in pieces.
Okay.
I never wanted anything else than having a way to convert the rest of the
Git programs to parse options.
Of course, my approach was not meant incremental, yours was.
But I never wanted anything as complicated as to merit a 7-mail patch
series that I have no time to even look at.
> Do you see now?
I do see now.
Sorry,
Dscho
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Boaz Harrosh @ 2008-06-24 17:19 UTC (permalink / raw)
To: David Jeske; +Cc: git
In-Reply-To: <48612ABE.6000104@panasas.com>
Boaz Harrosh wrote:
> David Jeske wrote:
>> As a new user, I'm finding git difficult to trust, because there are operations
>> which are destructive by default and capable of inadvertently throwing hours or
>> days of work into the bit bucket.
>>
>> More problematic, those commands have no discernible pattern that shows their
>> danger, and they need to be used to do typical everyday things. I'm starting to
>> feel like I need to use another source control system on top of the git
>> repository in case I make a mistake. My philosophy is simple, I never never
>> never want to throw away changes, you shouldn't either. Disks are cheaper than
>> programmer hours. I can understand wanting to keep things tidy, so I can
>> understand ways to correct the 'easily visible changes', and also avoid pushing
>> them to other trees, but I don't understand why git needs to delete things.
>>
>> For example, the following commands seem capable of totally destroying hours or
>> days of work. Some of them need to be used regularly to do everyday things, and
>> there is no pattern among them spelling out danger.
>>
>> git reset --hard : if another branch name hasn't been created
>
> git reset --hard is special see below
>
>> git rebase
>> git branch -D <branch> : if branch hasn't been merged
>> git branch -f <new> : if new exists and hasn't been merged
>> git branch -m <old> <new> : if new exists and hasn't been merged
>>
> The rest of the commands are recoverable from the log as people said
> but "git reset --hard" is not and should be *fixed*!
>
> I use git reset --hard in to separate and distinct functions.
> One - to move current branch head around from place to place.
> Two - Throw away work I've edited
>
> It has happened to me more then once that I wanted the first
> and also got the second as an un-warned bonus, to the dismay
> of my bosses. (What do I care if I need to write all this code
> again)
>
> I would like git-reset --hard to refuse if a git-diff HEAD
> (both staged and unstaged) is not empty. with a -f / -n logic
> like git-clean. (like git-clean none default config file override)
>
> Now I know that the first usage above could be done with
> git-branch -f that_branch the_other_branch. But that can
> not be preformed on the current branch and local changes
> are not lost.
>
> Lots of other potentially destructive git-commands check for local
> changes and refuse to operate. To remedy them git-reset --hard
> is recommended. I would prefer if there was a git-reset --clean -f/-n
> for the first case and git reset --hard only for the second usage
> case.
Sorry
git-reset --clean -f/-n for removing local changes
git reset --hard for moving HEAD on a clean tree only
>
> My $0.017
> Boaz
>
^ 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