* Re: Problem with bisect
From: Sean @ 2007-08-06 18:12 UTC (permalink / raw)
To: Larry Finger; +Cc: git
In-Reply-To: <46B623D6.7070809@lwfinger.net>
On Sun, 05 Aug 2007 14:24:06 -0500
Larry Finger <larry.finger@lwfinger.net> wrote:
> Sean wrote:
> > On Sun, 05 Aug 2007 11:02:21 -0500
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >
> >> I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and
> >> v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's
> >> wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we
> >> obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before
> >> bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this
> >> code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom
> >> is all the way to v2.6.16, which I think is the origin of the git process.
> >>
> >> Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by
> >> arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has
> >> been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the
> >> bug doesn't show on my machine.
> >>
> The git repo is git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git.
>
> The commands were:
>
> git bisect start
> git bisect bad
> git bisect good v2.6.22
>
> I'm using git version 1.4.4.2.g04509
The directory "drivers/net/wireless/bcm43xx-mac80211" is only introduced in
commit v2.6.23-rc1-1621-gd05daff. It didn't exist in v2.6.22.
You can see this with the command:
$ git log -- drivers/net/wireless/bcm43xx-mac80211
Where the last listed commit is d05daff. So of course there will be many
bisection points back to v2.6.22 where that directory just doesn't exist.
A bit of digging with Git shows this history for most of the files in
that directory:
renamed in v2.6.23-rc1-1621 as bcm43xx-mac80211
renamed in v2.6.21-rc1-809 as mac80211
renamed in v2.6.17-rc2-357 as d80211/bcm43xx
Imported in v2.6.16-1725 as bcm43xx-d80211
HTH,
Sean
^ permalink raw reply
* Re: question about git-submodule
From: Eran Tromer @ 2007-08-06 17:23 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, VMiklos, git
In-Reply-To: <20070805145922.GC999MdfPADPa@greensroom.kotnet.org>
On 2007-08-05 10:59, Sven Verdoolaege wrote:
>> BTW, is there any easy way to create a submodule directly inside the
>> supermodule's working tree, instead of cloning it as in the above example?
>
> Do you want to use the submodule porcelain or just the plumbing?
> If you simply want to add a submodule locally, "git add" will do that for
> you just fine. It's only when you want to make it easier for people who
> clone your superproject to get updates of the submodules that you
> should set up the information required by "git submodule" in .gitmodules
> (see end of module_add in git-submodule.sh).
If you just do "git add sub" (where sub is an existing repo subdir) then
any subsequent "git submodule update" predictably complains:
No submodule mapping found in .gitmodules for path 'sub'
And if you wire up .gitmodules manually, then "git submodule update"
chokes on the "git-fetch" in modules_update().
So I suggest extending "git submodule add" to handle existing
subdirectories by simply using them as-is instead of creating a new
clone. And "git submodule update" shouldn't try fetching when the commit
is already present locally.
Speaking of which, currently "git submodule" clones/fetches *all*
branches on the remote repository, which seems quite excessive given
that the supermodule's content references just one submodule commit. By
default, "git submodule add" should fetch only the needed head, and "git
submodule update" should fetch only the commit sha1 (if needed).
Eran
^ permalink raw reply
* [PATCH] check_repository_format_version(): run git_default_config() again
From: Johannes Schindelin @ 2007-08-06 17:32 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List, gitster
In-Reply-To: <2BA49414-54E0-4353-B237-7799B675FAE8@silverinsanity.com>
I broke this in "e90fdc39: Clean up work-tree handling". It is
needed, for example for interpreting core.pager before starting the
pager.
Noticed by Brian Gernhardt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
My first commit with git-gui! Yeah!
On Mon, 6 Aug 2007, Brian Gernhardt wrote:
> I don't have time to look into it, but something broke the
> core.pager variable. I've bisected it down to
> "e90fdc39b6903502192b2dd11e5503cea721a1ad: Clean up work-tree
> handling".
Thanks.
setup.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 4945eb3..35fa031 100644
--- a/setup.c
+++ b/setup.c
@@ -355,7 +355,8 @@ int check_repository_format_version(const char *var, const char *value)
free(git_work_tree_cfg);
git_work_tree_cfg = xstrdup(value);
inside_work_tree = -1;
- }
+ } else
+ return git_default_config(var, value);
return 0;
}
--
1.5.3.rc4.17.gb980
^ permalink raw reply related
* Re: Some ideas for StGIT
From: Pavel Roskin @ 2007-08-06 17:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0708060236x19674e4cjf04cec716ae6246c@mail.gmail.com>
On Mon, 2007-08-06 at 10:36 +0100, Catalin Marinas wrote:
> > The main point in favor of quilt is that it allows to edit the patches
> > with the text editor. One can pop all patches, edit them and push the
> > all back.
>
> If this is the main feature they need, they probably don't need git at
> all and quilt would be enough. I was using quilt before starting StGIT
> but the main problem I had with plain patches approach was the
> conflict solving.
OK, I understand it wasn't a good idea to ask for improvement on behalf
of others.
> StGIT does a 'git-diff | git-apply' as a patch push optimization and
> we could even cache the diff but the current algorithm is that if
> git-apply fails, StGIT falls back to a three-way merge and even an
> interactive user merge (via xxdiff for example). I find the three-way
> merging (automatic or interactive) much more powerful than fuzzy patch
> application.
I agree. I have no problem with what StGIT does internally.
> If we would allow patch editing, the 'stg push' algorithms wouldn't
> know when git-apply failed because the patch was edited or the base
> was changed. Falling back to the three-way merge would lose the edited
> patch. If one doesn't need three-way merging, quilt is good enough.
I suggest that StGIT saves the original patch and then does interdiff
between the old and the new patch. The original patch is applied first
just as it's applied now, and then the difference is applied on top of
that.
Temporary files should be kept in case of failure.
> Other advantages of the three-way merging is the detection of full
> patches or hunks merged upstream (the former can also be achieved by
> testing the reverse-application of the patches).
I'm fully with you here. Having git history can only be a good thing.
> I don't usually edit patches during development, I prefer to edit the
> source files and review the diff. It happens many times to move hunks
> between patches but I usually towards the bottom patches in the stack
> (using stg export and emacs) and the three-way merging automatically
> removes the merged hunks from top patches.
What I normally need to edit is the comments. Editing the code is
risky, although I may want to rename some badly named variable
introduced by the patch.
> > I don't suggest that StGIT gives up on the git-based storage, but this
> > mode of operation could be implemented in two ways.
> >
> > One is to have a command opposite to "export". It would read the files
> > that "export" produces, replacing the existing patches.
>
> As Yann said, we already have 'stg import --replace'.
Thanks!
> > Another approach would be to reexamine the patch after "stg refresh -es"
> > and to apply it instead of the original patch. If the patch doesn't
> > apply, the options would be to discard the edits or to re-launch the
> > editor.
>
> That's an interesting idea but maybe we should have a separate command
> like --edit-full to edit the full patch + log (part of the
> functionality already available in import).
I hate to be in a situation when I want to edit something but cannot,
because I didn't run some command before. What I like about StGIT is
that it allows me to do things my way.
I don't know if I want to change the patch before I see it.
> > Finally, it would be great to have TLS support in the mail command.
> > Mercurial has it, and looking at their mail.py, it doesn't seem to be
> > much work.
>
> Indeed, the SMTP Python objects already provide support for TLS via starttls().
And hg provides a great example.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: David Kastrup @ 2007-08-06 16:16 UTC (permalink / raw)
To: git
In-Reply-To: <86bqdkbq59.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> I don't even think it prudent to _offer_ the --show-touched option
> in a porcelain such as git-diff as long as purportedly read-only
> porcelain commands like git-status can trash the state: what is
> reported is not actually "touched" but something internal to the
> operation of git.
>
> At least not without a notice in the manual that this option might
> or might not work, depending on what one did previously.
Proposal: if this option is to stay, call it rather --show-stale since
that corresponds better with what the option actually does: show
whether git's inode cache went stale. It does _not_ show whether the
file has been touched (git-status does not touch files, for example).
--
David Kastrup
^ permalink raw reply
* git-sh-setup.sh:cd_to_toplevel problematic with symlinks
From: Matthias Lederhofer @ 2007-08-06 16:10 UTC (permalink / raw)
To: git
cd_to_toplevel takes the output of git rev-parse --show-cdup and feeds
it to cd. The problem is that cd uses PWD to do what the user means
when saying cd .., i.e. it goes to /foo when in /foo/bar even though
/foo/bar might be a symlink. Example:
(in an existing git repository)
/tmp/foo$ mkdir -p a/b
/tmp/foo$ ln -s a/b c
/tmp/foo$ cd c
/tmp/foo/c$ git fetch . master:master
git-fetch: line 108: /FETCH_HEAD: Permission denied
Is there any way to tell cd to ignore $PWD?
Another option is to have a new option to rev-parse which shows the
absolute path to tho toplevel.
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: David Kastrup @ 2007-08-06 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <7vir7wmk84.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> But I'd really think that what should be done (if anything has to be done
>> at all) is to introduce a config variable which triggers the same logic in
>> git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.
>
> Sorry, I don't follow at all. The diff toolchain works all
> inside core without having to write a temporary index out, which
> was the issue the commit you are quoting was about.
>
> In any case, enough discussion. Here is an updated patch, which
> I _could_ be pursuaded to consider for inclusion after v1.5.3
> happens, if there are enough agreements and Acks.
Ack, ack, ack. The current default behavior is plainly unusable. For
example, I've rsynced -a a tree including .git, and suddenly git-diff
goes out of kilter. And stops doing so when running git-status once.
This is the worst kind of "unpredictable", and I don't care one bit
that there are conceivable use cases.
I don't even think it prudent to _offer_ the --show-touched option in
a porcelain such as git-diff as long as purportedly read-only
porcelain commands like git-status can trash the state: what is
reported is not actually "touched" but something internal to the
operation of git.
At least not without a notice in the manual that this option might or
might not work, depending on what one did previously.
--
David Kastrup
^ permalink raw reply
* core.pager handling broken
From: Brian Gernhardt @ 2007-08-06 15:56 UTC (permalink / raw)
To: Git Mailing List
I don't have time to look into it, but something broke the core.pager
variable. I've bisected it down to
"e90fdc39b6903502192b2dd11e5503cea721a1ad: Clean up work-tree
handling". With this commit:
$ git config core.pager
tig
$ git log
# Uses less
$ GIT_PAGER=tig git log
# Uses tig
I don't have time to track it down right now (I'm off visiting
family), but will look into it tomorrow unless someone thinks it's
obvious and points it out before then.
~~ Brian
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Matthias Lederhofer @ 2007-08-06 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vir7wmk84.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> In any case, enough discussion. Here is an updated patch, which
> I _could_ be pursuaded to consider for inclusion after v1.5.3
> happens, if there are enough agreements and Acks.
I like this new behaviour but I don't see the old one too often
either.
^ permalink raw reply
* Re: Some ideas for StGIT
From: Josef Sipek @ 2007-08-06 15:19 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, Yann Dirson, git
In-Reply-To: <1186406768.10627.50.camel@dv>
<shameless plugs>
On Mon, Aug 06, 2007 at 09:26:08AM -0400, Pavel Roskin wrote:
> On Mon, 2007-08-06 at 10:49 +0100, Catalin Marinas wrote:
>
> > The story for the 'new -s' option was that with StGIT (not possible
> > with Quilt), one can start modifying the local tree and only create a
> > patch afterwards.
>
> And that's what I really like about StGIT. I like that I can edit code
> without worrying (too much) about the state of the repository.
guilt-new -f <patchname>
> > The newly created patch is always empty, even if
> > there were local changes and showing them was useful for writing the
> > patch description. One can use refresh for checking the changes in.
> > Indeed, the 'new' command can be improved to have part of the
> > 'refresh' functionality, though I don't really like this duplication.
>
> It should be fine as long as the code is reused IMHO.
Agreed.
> > I think we should put some default patch description.
>
> I agree. Sometimes it's too early to write a description.
If Guilt doesn't find a description in the patch file during push, it uses
"patch $patchname" as the commit message. This makes it enough of an
eye-sore that you notice before you submit the patches upstream :)
Josef 'Jeff' Sipek.
--
Failure is not an option,
It comes bundled with your Microsoft product.
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-06 14:37 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Dmitry Kakurin, Marius Storm-Olsen, git
In-Reply-To: <e7bda7770708060730t7c0713c4m6abe42d929d847b0@mail.gmail.com>
Hi,
On Mon, 6 Aug 2007, Torgil Svensson wrote:
> On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > > > 3. "gitk --all" said "Error reading commits: fatal: write
> > > > > failure on stdout: Invalid argument"
>
> > I have to wonder how you called it... From msys.bat, cd'ing into a
> > valid repository, I had no issues whatsoever.
>
> I called it from rxvt. I tried it now under cmd and it's all good. Did
> you try rxvt in this case?
I had no issues like that in rxvt. But "git push" via ssh was a no go.
even with the "ssh://.." syntax. Since it works in cmd, I'll stay with
cmd for now, but I'd like to see a working rxvt.
> I notice that with your net installer (great job btw!), I get the
> msysgit.git reop under /.git and the mingw.git repo under /git/.git but
> there is no /git in /.gitignore. Is this overlap intended? Isn't this a
> case for submodules?
Exactly. My bad. Dmitry pointed out that I should not have done that,
and I'm in the middle of setting it up as a submodule.
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Torgil Svensson @ 2007-08-06 14:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708060054020.14781@racer.site>
On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> NOTE: earlier installers included msys-rxvt.bat. I now _know_ for a fact
> that a lot of things are strangely broken under Rxvt. For example,
> creating an ssh key, of all things.
> > > > 2. rxvt-terminal had some freezes
> Those "freezes" were due to the fact that Rxvt incorrectly updates stderr
> in a blocking way, or not at all (don't know which). There are more
> things that do not work in Rxvt, and only after trying the same in cmd
> (which I do not like for various reasons) I found out that rxvt.exe is at
> fault.
>
> I would be glad if somebody managed to compile rxvt herself and fix all
> those bugs (see http://code.google.com/p/msysgit/ for a short list of the
> most pressing issues I found). As it is, I have enough work to do with
> the rest of msysGit, and for the moment, I can at least work in cmd. Even
> ssh push works.
>
It looks like rxvt is evil. I'll try to get other terminals working
like that one Marius suggested. Although msys/bash makes up for most
of the annoyances I dislike the cmd-terminal to the point that it's a
real issue for me [deep settled in my neuron configuration].
> > > > 3. "gitk --all" said "Error reading commits: fatal: write failure on
> > > > stdout: Invalid argument"
> I have to wonder how you called it... From msys.bat, cd'ing into a valid
> repository, I had no issues whatsoever.
I called it from rxvt. I tried it now under cmd and it's all good. Did
you try rxvt in this case?
I notice that with your net installer (great job btw!), I get the
msysgit.git reop under /.git and the mingw.git repo under /git/.git
but there is no /git in /.gitignore. Is this overlap intended? Isn't
this a case for submodules?
//Torgil
^ permalink raw reply
* Re: typo in http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
From: Julian Phillips @ 2007-08-06 14:26 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <46B72A8E.3040602@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1039 bytes --]
On Mon, 6 Aug 2007, Toralf Förster wrote:
> Hello,
>
> shouldn't " at the tip of one of your branches" better written as " at the
> top of one of your branches".
>
> BTW one question: I run a simple test unit (only build tests) against the
> latest git tree, which is updated with "git pull" once a day.
>
> If I want to make some tests with a previous kernel version - say v2.6.20 and
> switch then back to HEAD to continue with my common test suite, would the
> following be ok : ?
>
> $> git checkout v2.6.20
This will change HEAD to be a detached checkout of v2.6.20
> $> <do something useful with it>
> $> git reset
This will not change HEAD back.
something like this perhaps?
$> MY_HEAD=$(git symbolic-ref HEAD)
$> git checkout v2.6.20
$> <...>
$> git reset --hard $MY_HEAD
no doubt there is a more cunning method ...
--
Julian
---
<SpanKY> hmm, blade iii comes out the 8th
<SpanKY> we could catch a flick and have anal sex in the back
<jforman> holy jesus, /me cancels his plans
^ permalink raw reply
* [PATCH] git-am: initialize variable $resume on startup
From: Gerrit Pape @ 2007-08-06 14:15 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20070803201405.GB12430@artemis.corp>
git-am expects the variable $resume to be empty or unset, which might not
be the case if $resume is set in the user's environment. So initialize
it to an empty value on startup.
The problem was noticed by Pierre Habouzit and reported through
http://bugs.debian.org/435807
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-am.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 6cf0eee..b5ed8ca 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -103,7 +103,8 @@ It does not apply to blobs recorded in its index."
}
prec=4
-dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary= resolvemsg=
+dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary=
+resolvemsg= resume=
git_apply_opt=
while case "$#" in 0) break;; esac
--
1.5.3.GIT
^ permalink raw reply related
* typo in http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
From: Toralf Förster @ 2007-08-06 14:05 UTC (permalink / raw)
To: git
Hello,
shouldn't " at the tip of one of your branches" better written as " at
the top of one of your branches".
BTW one question: I run a simple test unit (only build tests) against
the latest git tree, which is updated with "git pull" once a day.
If I want to make some tests with a previous kernel version - say
v2.6.20 and switch then back to HEAD to continue with my common test
suite, would the following be ok : ?
$> git checkout v2.6.20
$> <do something useful with it>
$> git reset
Thanks for an answer
--
Toralf
^ permalink raw reply
* Re: Some ideas for StGIT
From: Karl Hasselström @ 2007-08-06 13:52 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1186404125.10627.30.camel@dv>
On 2007-08-06 08:42:05 -0400, Pavel Roskin wrote:
> On Mon, 2007-08-06 at 11:56 +0200, Karl Hasselström wrote:
>
> > I never really understood why commit message editing had to be
> > part of the "refresh" command. If it were a separate command and
> > not tied to refresh, we could allow editing the message (and
> > author, committer, date, ...) of any commit in the stack -- since
> > the tree objects would be unchanged, we could just reuse the same
> > tree objects when rewriting the commit objects on top of it.
>
> Purely from the code standpoint, yes, it should be a separate
> command. But it may be practical to have both in one command, since
> I commonly need to change the description after changing the code.
Sure. I don't have any objection to making
stg refresh -e
be equivalent to
stg refresh && stg edit-patch-message <topmost-patch>
What I'm objecting to is being forced to refresh when I just want to
edit the message. (And, to a lesser degree, having to manually push
and pop to make the patch topmost before I can edit its message.)
Obviously not annoyed enough to have written a patch for it yet,
though. :-)
> We need to think what would be convenient for the normal workflow.
Of course.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Some ideas for StGIT
From: Pavel Roskin @ 2007-08-06 13:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, git
In-Reply-To: <b0943d9e0708060249h4a3f59bobfac8f9014aca82f@mail.gmail.com>
On Mon, 2007-08-06 at 10:49 +0100, Catalin Marinas wrote:
> The story for the 'new -s' option was that with StGIT (not possible
> with Quilt), one can start modifying the local tree and only create a
> patch afterwards.
And that's what I really like about StGIT. I like that I can edit code
without worrying (too much) about the state of the repository.
> The newly created patch is always empty, even if
> there were local changes and showing them was useful for writing the
> patch description. One can use refresh for checking the changes in.
> Indeed, the 'new' command can be improved to have part of the
> 'refresh' functionality, though I don't really like this duplication.
It should be fine as long as the code is reused IMHO.
> > Especially confusing is that if there are already applied patches, the
> > diff shown is the one of the previous top patch
>
> Are you sure it doesn't only show the local changes (which you might
> want to add in a new patch)?
I confirm this bug.
> I think we should put some default patch description.
I agree. Sometimes it's too early to write a description.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Documentation/Makefile: remove cmd-list.made before redirecting to it.
From: David Kastrup @ 2007-08-06 13:05 UTC (permalink / raw)
To: git
If cmd-list.made has been created by a previous run as root, output
redirection to it will fail. So remove it before regeneration.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 97ee067..120e7c0 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -120,6 +120,7 @@ $(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl $(MAN1_TXT)
perl ./cmd-list.perl
+ $(RM) $@
date >$@
git.7 git.html: git.txt core-intro.txt
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* [PATCH] Documentation/git-commit.txt: correct bad list formatting.
From: David Kastrup @ 2007-08-06 12:56 UTC (permalink / raw)
To: git
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/git-commit.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 63599d3..e54fb12 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -19,6 +19,7 @@ Use 'git commit' to store the current contents of the index in a new
commit along with a log message describing the changes you have made.
The content to be added can be specified in several ways:
+
1. by using gitlink:git-add[1] to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* Re: Another question about importing SVN with fast-import
From: Julian Phillips @ 2007-08-06 13:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070717033840.GK32566@spearce.org>
On Mon, 16 Jul 2007, Shawn O. Pearce wrote:
> Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> However, how do you copy a file from a
>> particular revision?
>
> and sometimes not so much. You can't do that right now. I've wanted
> to open up the data subcommand to allow another form that lets you
> specify data from a branch and file path (thus selecting a blob
> from another revision) but I haven't gotten around to it. I also
> don't have time to do it during the earlier part of this week.
> Maybe I'll get to it later near the end of the week.
I was wondering if this was still a vague todo item, or if it was being
worked on? It really is the biggest thing blocking my import at the
moment and I'm willing to have a bash at it myself, but I didn't want to
start messing around inside the fast-import code if someone else was
already there ...
>
> It shouldn't be too difficult now with the tree_content_get()
> function that I recently defined for the C/R commands. The SHA-1
> comes back in the tree_entry leaf, but that codepath is only valid
> for the tip of a branch that fast-import knows about in memory.
> If it doesn't then you probably need to fallback into raw tree
> parsing. Ugh.
>
> The way prior frontends have handled this is they assigned marks
> to every blob, and then had a translation table within the frontend
> of revision->mark, so that anytime it needed a given revision of a
> file it knew what mark to send to fast-import. This does require
> that the frontend maintain basically everything...
Not sure how that would apply to trees ... and I would rather minimise the
amount of state retained in the frontend.
--
Julian
---
Disco is to music what Etch-A-Sketch is to art.
^ permalink raw reply
* Re: Some ideas for StGIT
From: Pavel Roskin @ 2007-08-06 12:42 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070806095623.GA23349@diana.vm.bytemark.co.uk>
On Mon, 2007-08-06 at 11:56 +0200, Karl Hasselström wrote:
> I never really understood why commit message editing had to be part of
> the "refresh" command. If it were a separate command and not tied to
> refresh, we could allow editing the message (and author, committer,
> date, ...) of any commit in the stack -- since the tree objects would
> be unchanged, we could just reuse the same tree objects when rewriting
> the commit objects on top of it.
>
> That's obviously not going to work if we allow editing of the patch.
> But patch editing isn't a good fit as a refresh switch either, since
> it's not at all related to replacing the tree of the current patch
> with the working tree.
Purely from the code standpoint, yes, it should be a separate command.
But it may be practical to have both in one command, since I commonly
need to change the description after changing the code.
We need to think what would be convenient for the normal workflow.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johannes Schindelin @ 2007-08-06 12:17 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Miles Bader
In-Reply-To: <200708060946.12793.johan@herland.net>
Hi,
On Mon, 6 Aug 2007, Johan Herland wrote:
> On Monday 06 August 2007, Johannes Schindelin wrote:
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > >> But I'm wondering whether we'd want to include it in git by default
> > > >> (instead of having to tell confused users to add the alias).
> > > >
> > > > I recommend against that, too. All too often, I have some temporary files
> > > > in the working tree, and I'll be dimmed if I'm the only one. So
> > > > "addremove" adds too much possibility for pilot errors.
> > >
> > > "Recommend against it"? Why?
> >
> > Didn't I say that? It just _asks_ for pilot errors.
>
> Ok, in that spirit I also suggest removing _all_ git plumbing-level commands
> from the default installation.
Oh, come on. You were talking about a porcelain command.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Johannes Schindelin @ 2007-08-06 11:51 UTC (permalink / raw)
To: Steven Grimm; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <46B6EBAB.4050805@midwinter.com>
Hi,
On Mon, 6 Aug 2007, Steven Grimm wrote:
>
> [I pointed out how dangerous committing hunks selectively can be]
>
> So I guess my point, after all that, is just that assumptions that are
> valid in the context of one workflow are not necessarily as valid in
> others, and that even in a particular context, not all changes are
> created equal.
Right. But I think a warning _is_ needed. So that everybody considers if
it is safe in _her_ workflow.
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-06 11:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708061123450.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
Johannes Schindelin said the following on 06.08.2007 12:24:
> Hi,
>
> On Mon, 6 Aug 2007, Marius Storm-Olsen wrote:
>
>> Instead of hacking away on this old terminal, what about simply including
>> another nice Open Source project?
>>
>> On Windows we have a replacement terminal, which has all the features you
>> want, and also supports tabs like Konsole. I've used it for several years, and
>> it works great. Have a look and see if you like it, then we can add it to the
>> repo:
>> http://sourceforge.net/projects/console/
>>
>> Original name, ey? :-)
>
> That sounds awesome. However, from their sourceforge page, it seems they
> support only 2k and xp? What about 95 and nt?
Hmm, nope. Just tried it on 98, and that didn't fly. It requires
symbols to do top-level transparency, which is only accessible from
Win2K and later.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Johannes Schindelin @ 2007-08-06 10:42 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <BD28FA320B7749FFBE3135FE92380BCE@ntdev.corp.microsoft.com>
Hi,
On Mon, 6 Aug 2007, Dmitry Kakurin wrote:
> environment.c caches results of many getenv calls. Under MinGW setenv(X)
> invalidates all previous values returned by getenv(X) so cached values
> become dangling pointers.
>
> Added cache-aware function set_git_dir to complement get_git_dir
The real problem here: mingw.git did not merge with upstream git.git in a
long time (mainly because its maintainer is on holiday). In the meantime,
set_git_dir() is already there!
I had more problems than I thought with setting up a fork of mingw.git.
It seems that the relative alternates path to mingw.git is followed, but
not that one from mingw.git to git.git. So I could upload, but not fetch.
So I propose to use http://repo.or.cz/w/git/mingw4msysgit.git/ in the
meantime. (Just give me your account name, and you'll be able to push to
it.)
BTW your patch was white-space mangled.
Ciao,
Dscho
^ 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