* Re: git on Cygwin: Not a valid object name HEAD
From: Mark Levedahl @ 2007-08-08 16:41 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Linus Torvalds, Git Mailing List, Shawn O. Pearce,
Sebastian Schuberth
In-Reply-To: <A2397231-1B81-4AD4-87CB-8FF8FB9BA89C@zib.de>
On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> The bottom line for me is, git does not yet support Windows in a
> usable way for the organizations that I need to convince.
>
> Steffen
>
Have you considered jumping in to help on the msys git port Johannes
Schindelin is working? He has very generously offered to do
essentially everything except find bugs, the latter because he does
not actually use Windows so can't, and is clearly putting a great deal
of effort into this. A stable and complete Windows port may be much
closer than you think.
Mark
^ permalink raw reply
* Re: git-svn: commit author x commit committer issue
From: Peter Baumann @ 2007-08-08 17:13 UTC (permalink / raw)
To: Richard MUSIL; +Cc: git
In-Reply-To: <46B9C92B.3000000@st.com>
On Wed, Aug 08, 2007 at 03:46:19PM +0200, Richard MUSIL wrote:
> Normally, when patch is applied, git distinguishes commit author and
> commit committer (relying on info from patch).
> However, after the patches are committed to svn repository using:
> git-svn dcommit
> author and committer data are set to same values (or at least time and
> date, I cannot verify it for names).
> I wonder if there is any reason for this behavior, because I would
> definitely like to keep original commit info (which came from patch) in
> my git repository.
I think it is because in SVN, you can't differentiate between author and
committer. And git-svn just commits every local commit to svn, and after
that, it throws away your local commits and uses the info from the
reimported svn commits to recreate those thrown away commits. Thats why
you loose your author name and also your commit date.
Ok, this was a little too simplified, but describes roughly what happens
if you dcommit your changes.
-Peter
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Johannes Schindelin @ 2007-08-08 17:20 UTC (permalink / raw)
To: Mark Levedahl
Cc: Steffen Prohaska, Junio C Hamano, Linus Torvalds,
Git Mailing List, Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <30e4a070708080941j49b3d58cxc39bbe65f2fee9d5@mail.gmail.com>
Hi,
On Wed, 8 Aug 2007, Mark Levedahl wrote:
> On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >
> > The bottom line for me is, git does not yet support Windows in a
> > usable way for the organizations that I need to convince.
> >
> > Steffen
> >
>
> Have you considered jumping in to help on the msys git port Johannes
> Schindelin is working? He has very generously offered to do
> essentially everything except find bugs, the latter because he does
> not actually use Windows so can't, and is clearly putting a great deal
> of effort into this. A stable and complete Windows port may be much
> closer than you think.
To be fair, we are already a team of five working on it. The 3rd
generation of the net installer works as flawlessly as the first, but
msysgit.git is a superproject now, containing the complete build
environment you need, and has git/mingw/4msysgit.git as a submodule (yes,
that is a fork of a fork; they work now on repo.or.cz).
Please find it on
http://msysgit.googlecode.com/
(It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It
already passes all tests, is able to start gitk and git-gui, and more is
to come!
And no, I did not agree to do _everything_. I agreed to do things _when I
get something in return_.
For example, we have a functional script sitting in msysgit.git which
builds a complete WinGit installer (WinGit being the code name for "Git on
MSys without the whole build environment").
It is incomplete in only a few issues:
- it does not install anything in the start menu
- it does not install any short cut on the Desktop
- it does not install anything in the Quick Launch bar
- it does not include a nice WelcomeToGit.html, to be launched
after a successful install
- it does not contain a nice way to start git-gui (you have to
start it by hand from the command line inside bash)
- etc.
So go for it, everybody, or alternatively do not even bother to whine.
Ciao,
Dscho
P.S.: I'll be not really available for a few days, starting from tomorrow,
so do use the mailing list to keep in touch with others working on msysgit
or 4msysgit, and do use the mob branch (you can bug the project members
listed on the homepage to cherry-pick, sign off and push if need be).
^ permalink raw reply
* Re: [PATCH] patch open-editor-at-top-line
From: David Kastrup @ 2007-08-08 17:43 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: git
In-Reply-To: <20070808151145.GA2897@dnb.sw.ru>
Dmitry Monakhov <dmonakhov@openvz.org> writes:
> When i use "guilt series -e" for realy long series file
> it is not confortable always search current top patch line.
> IMHO editor have to start at the top patch automaticaly.
> Btw: open_editor_at_line may be useful in other places
>
> +# usage: open_editor_at_line <editor> <filename> <line>
> +# try to open editor with "filename"" at "line"
> +# different editors use different syntax for start line parameter
> +# so the only thing we can do is just compare with known editiors
> +# and ignore line if editor is unknown.
> +open_editor_at_line()
> +{
> + editor_name=$1
> + file_name=$2
> + line_pos=$3
> + case "$editor_name" in
> + "vi" |"vim")
> + $editor_name $file_name +$line_pos;;
> + "emacs")
> + $editor_name $file_mame:$line_pos;;
^^^^^^^^^^^^^^^^^^^^^^
You have not actually tested this patch.
> + *)
> + # editor is unknown, line_pos is just ignored
> + $editor_name $file_name;;
> + esac
> + return $?
> +}
> +
This does not make much sense. Pretty much every editor that can be
placed into $EDITOR/$VISUAL will understand the
$EDITOR +line filename
line convention (and if they don't, the damage is small). Certainly
Emacs does so. I don't know the situation under Windows, but in Unix
this has been the state for editors for eternity.
It turns out that I recently patched the git_editor function in
git-setup-sh.sh to take multiple arguments, and this should come in
handy: just do
git_editor "+$line_pos" "$filename"
and this should open the desired editor at the right line number.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-svn: Finding the svn-URL of the current branch in git
From: Matthias Kleine @ 2007-08-08 18:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7gm4cdv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Parents' order and which branch you are on may not have anything
> to do with each other. Somebody else may have pulled a while on
> b, and you might have pulled from him the merge he created by
> doing so while you are on branch a.
>
You're right, I didn't think of that. While pondering this I came up
with another problem: git-svn currently remembers which svn-branch a
commit belongs to by including this information in the git commit log
message.
This way it is not possible to have one git-commit appear in more than
one svn branch. Maybe it's better to store this git-commit->svn-branch
mapping somewhere else. Although it's probably even better to completely
switch to git :)
Matthias
^ permalink raw reply
* [PATCH] Mod. gitk to support REBASE (with stash support).
From: Alexandre Bourget @ 2007-08-08 18:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: paulus, Alexandre Bourget
---
Adds a context menu for commits, so that a 'rebase' can be done.
Optionally, it will ask if you want to 'stash' current work before doing so.
TODO: better error handling.
gitk | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index f74ce51..558b7bb 100755
--- a/gitk
+++ b/gitk
@@ -898,6 +898,8 @@ proc makewindow {} {
-command cherrypick
$rowctxmenu add command -label "Reset HEAD branch to here" \
-command resethead
+ $rowctxmenu add command -label "Rebase HEAD branch on this commit" \
+ -command rebasehead
set fakerowmenu .fakerowmenu
menu $fakerowmenu -tearoff 0
@@ -5593,6 +5595,7 @@ proc rowmenu {x y id} {
if {$id ne $nullid && $id ne $nullid2} {
set menu $rowctxmenu
$menu entryconfigure 7 -label "Reset $mainhead branch to here"
+ $menu entryconfigure 8 -label "Rebase $mainhead branch on this commit"
} else {
set menu $fakerowmenu
}
@@ -5972,6 +5975,41 @@ proc cherrypick {} {
notbusy cherrypick
}
+proc rebasehead {} {
+ global mainheadid mainhead rowmenuid confirm_ok
+ global localfrow localirow
+
+
+ set head $mainhead
+ set id $rowmenuid
+
+ set confirm_ok 0
+
+ if {$localfrow != -1 || $localirow != -1} {
+ # There's something to stash.
+ set confirm_ok [confirm_popup "There are some local modifications.\n\nDo you want to git-stash any changes before doing a rebase?\n\n(They will be reapplied right after, and stash will be *cleared*)"]
+ }
+
+ nowbusy rebasehead
+ update
+
+ if {$confirm_ok} {
+ exec git stash save
+ }
+
+ # TODO: error handling.
+ exec git rebase $id
+
+ if {$confirm_ok} {
+ exec git stash apply stash@{0}
+ exec git stash clear
+ }
+
+ notbusy rebasehead
+ updatecommits
+}
+
+
proc resethead {} {
global mainheadid mainhead rowmenuid confirm_ok resettype
global showlocalchanges
--
1.5.3.rc4.24.g5b56a
^ permalink raw reply related
* Git'ing a non-labeled set of sources
From: Sparks, Sam @ 2007-08-08 18:59 UTC (permalink / raw)
To: git
Hello All,
Please excuse me if this is an ignorant question; I'm new to git and my
have overlooked something in the documentation.
I'm attempting to obtain a snapshot of source code from an unlabeled git
branch in a public repository. I've found in the documentation that a
timestamp cannot be used to specify a particular version of source code,
but I believe I can work with the commit value as returned by 'git
show'.
However, I have been unsuccessful in my attempts to use this identifier
to clone or checkout the associated source tree. Has anyone been
successful in using git to successfully replicate an unlabeled version
of sources in a repository?
Here is my latest attempt:
/dir_i_want_to_replicate $ git show --pretty=short
commit 5b1313fb2758ffce8b624457f777d8cc6709608d
Author: ....
/replication_dir $ git clone git://www.denx.de/git/u-boot.git
u-boot-mpc83xx
Blah blah blah..
100% (4378/4378) done
/replication_dir/u-boot-mpc83xx/ $ git checkout
5b1313fb2758ffce8b624457f777d8cc6709608d
error: pathspec '5b1313fb2758ffce8b624457f777d8cc6709608d' did not match
any.
Any suggestions would be greatly appreciated.
Thanks in advance,
Sam Sparks
^ permalink raw reply
* Re: resumable git-clone?
From: Junio C Hamano @ 2007-08-08 19:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708081012110.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now here is a thought: after an interrupted fetch, you could do a
> (possibly expensive) analysis what commits are dangling, but do not
> contain broken links in their _complete_ history. Then mark them as
> (temporary) refs.
That's all too elaborate and sounds fairly expensive.
I think another practical solution is to reduce the need to
resume git-clone, and I foresee a nice side effect.
Let's talk a bit about the side effect first. Often I see
people wondering...
- I am forking off of somebody's big project;
- I want to publish the result of _my_ part of the work;
- I cannot afford the diskspace nor the bandwidth at the
hosting service to offer the whole project, but my own work
on top of the upstream is small enough;
So I've been thinking about teaching the server side, when
responding to a fetch request, to be able to say something like
"Sorry but this repository is for fetching by people who have at
least these commits from that other project I am a fork of."
We make that "at least these from that other project" part
machine readable, and git-fetch request git-clone makes can
redirect itself to fill the prerequisites before attempting to
go there again.
And one way of doing that "at least these commits" part could be
a pre-built, well known bundle. The bulk of the older history
of a repository insanely large for your bandwidth requirements
could be made to a single bundle [*1*], and distributed from
other places like mirrored HTTP servers, or even from torrent
network. The pre-built bundle does not have to be built too
often. Probably after every other big release would do.
Once we have such a support, cloning from a regular full
repository ove an unreliable connection could fall back on
getting a bundle (a regular repository does not have to refuse
to serve downloaders that do not have the prerequisites, but
it could still suggest that as an alternate method to fall back
on.
[Footnote]
*1* Sheesh. While I was writing this I noticed that the current
'git bundle' is suitable only for incremental sneakernet but
not for this particular use case.
$ git bundle create 2612.bndl v2.6.12
does not work, although
$ git bundle create 2612-2613.bndl v2.6.12..v2.6.13
does. We need to fix this.
^ permalink raw reply
* Re: git-svn: Finding the svn-URL of the current branch in git
From: Peter Baumann @ 2007-08-08 19:25 UTC (permalink / raw)
To: Matthias Kleine; +Cc: git
In-Reply-To: <f9d3ce$1lo$1@sea.gmane.org>
On Wed, Aug 08, 2007 at 08:51:55PM +0200, Matthias Kleine wrote:
> Junio C Hamano wrote:
>> Parents' order and which branch you are on may not have anything
>> to do with each other. Somebody else may have pulled a while on
>> b, and you might have pulled from him the merge he created by
>> doing so while you are on branch a.
>
> You're right, I didn't think of that. While pondering this I came up with
> another problem: git-svn currently remembers which svn-branch a commit
> belongs to by including this information in the git commit log message.
Thats true.
> This way it is not possible to have one git-commit appear in more than one
> svn branch.
But there is no way that a git commit could appear on several branches
in SVN, because SVN doesn't have the concept of multiple parents. So you
can't have a commit which describes a merge of two branches, because SVN
can't store the 2 parents. But you could have 2 commits which describe
the same state (e.g. same root tree), but are on seperate branches.
t:= commits on trunk
b:= commits on branch 'b'
repo1:
t <-trunk
|
t
| \
t b <- branch
| /
t
But this graph is only local to the committers repo. Another person
using git-svn to track the SVN repo sees this
repo2/SVN repo:
t <-trunk
|
t
|
t b <- branch
| /
t
So if you do a 'git merge trunk' in repo1 on branch 'branch', git-svn
should produce something like this:
repo2/SVN repo:
trunk-> t t' <- branch
| |
t t'
| |
t b
| /
t
The interesting case is what it will produce in *YOUR* repo. There are 2
possibilities:
repo1 (I): repo1 (II)
tb <-trunk <-branch trunk-> t b <- branch
| | |
tb t b
| \ | \|
t b <- branch t b
| / | /
t t
(I) would be nicer, but propably more difficult the way git-svn works now.
(II) would also be possible and more in line what other people importing
from SVN see.
These are the possible ways to describe the merge of 2 SVN branches.
-Peter
^ permalink raw reply
* [PATCH] cmd-list.perl: Alphabetize command list
From: Steve Hoelzer @ 2007-08-08 19:30 UTC (permalink / raw)
To: git mailing list, Junio C Hamano
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
---
Documentation/cmd-list.perl | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 2143995..cef9ab7 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -80,10 +80,10 @@ git-blame
ancillaryinterrogators
git-branch mainporcelain
git-bundle mainporcelain
git-cat-file plumbinginterrogators
-git-checkout-index plumbingmanipulators
-git-checkout mainporcelain
git-check-attr purehelpers
git-check-ref-format purehelpers
+git-checkout mainporcelain
+git-checkout-index plumbingmanipulators
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
git-citool mainporcelain
@@ -91,6 +91,7 @@ git-clean mainporcelain
git-clone mainporcelain
git-commit mainporcelain
git-commit-tree plumbingmanipulators
+git-config ancillarymanipulators
git-convert-objects ancillarymanipulators
git-count-objects ancillaryinterrogators
git-cvsexportcommit foreignscminterface
@@ -98,9 +99,9 @@ git-cvsimport foreignscminterface
git-cvsserver foreignscminterface
git-daemon synchingrepositories
git-describe mainporcelain
+git-diff mainporcelain
git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
-git-diff mainporcelain
git-diff-tree plumbinginterrogators
git-fast-import ancillarymanipulators
git-fetch mainporcelain
@@ -121,7 +122,6 @@ git-imap-send foreignscminterface
git-index-pack plumbingmanipulators
git-init mainporcelain
git-instaweb ancillaryinterrogators
-gitk mainporcelain
git-local-fetch synchingrepositories
git-log mainporcelain
git-lost-found ancillarymanipulators
@@ -130,10 +130,10 @@ git-ls-remote
plumbinginterrogators
git-ls-tree plumbinginterrogators
git-mailinfo purehelpers
git-mailsplit purehelpers
+git-merge mainporcelain
git-merge-base plumbinginterrogators
git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
-git-merge mainporcelain
git-merge-one-file purehelpers
git-merge-tree ancillaryinterrogators
git-mergetool ancillarymanipulators
@@ -157,26 +157,25 @@ git-rebase mainporcelain
git-receive-pack synchelpers
git-reflog ancillarymanipulators
git-relink ancillarymanipulators
-git-repack ancillarymanipulators
-git-config ancillarymanipulators
git-remote ancillarymanipulators
+git-repack ancillarymanipulators
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
git-reset mainporcelain
-git-revert mainporcelain
git-rev-list plumbinginterrogators
git-rev-parse ancillaryinterrogators
+git-revert mainporcelain
git-rm mainporcelain
git-runstatus ancillaryinterrogators
git-send-email foreignscminterface
git-send-pack synchingrepositories
+git-sh-setup purehelpers
git-shell synchelpers
git-shortlog mainporcelain
git-show mainporcelain
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
-git-sh-setup purehelpers
git-ssh-fetch synchingrepositories
git-ssh-upload synchingrepositories
git-stash mainporcelain
@@ -200,3 +199,4 @@ git-verify-pack
plumbinginterrogators
git-verify-tag ancillaryinterrogators
git-whatchanged ancillaryinterrogators
git-write-tree plumbingmanipulators
+gitk mainporcelain
--
1.5.3.rc3.141.g53d646
^ permalink raw reply related
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: Peter Baumann @ 2007-08-08 19:31 UTC (permalink / raw)
To: Alexandre Bourget; +Cc: Git Mailing List, paulus
In-Reply-To: <1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com>
On Wed, Aug 08, 2007 at 02:33:48PM -0400, Alexandre Bourget wrote:
> ---
> Adds a context menu for commits, so that a 'rebase' can be done.
>
> Optionally, it will ask if you want to 'stash' current work before doing so.
>
> TODO: better error handling.
>
[...long patch ...]
> + # TODO: error handling.
> + exec git rebase $id
> +
> + if {$confirm_ok} {
> + exec git stash apply stash@{0}
'git stash apply' could fail with merge conflicts ...
> + exec git stash clear
and here you are throwing the stash away!
> + }
> +
> + notbusy rebasehead
> + updatecommits
> +}
-Peter
^ permalink raw reply
* Re: Submodules
From: Junio C Hamano @ 2007-08-08 19:33 UTC (permalink / raw)
To: skimo; +Cc: Dmitry Kakurin, Johannes Schindelin, git
In-Reply-To: <20070808104117.GK999MdfPADPa@greensroom.kotnet.org>
There was a discussion about the semantics currently
implemented, as a subset of what we might want to eventually
have, and some recommended that we mention where things stand
now in the release notes.
How about this?
diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt
index 21bb1fc..901f813 100644
--- a/Documentation/RelNotes-1.5.3.txt
+++ b/Documentation/RelNotes-1.5.3.txt
@@ -9,6 +9,19 @@ Updates since v1.5.2
* The submodule support has Porcelain layer.
+ Note that the current submodule support is minimal and this is
+ deliberately so. A design decision we made is that operations
+ at the supermodule level do not recurse into submodules by
+ default. The expectation is that later we would add a
+ mechanism to tell git which submodules the user is interested
+ in, and this information might be used to determine the
+ recursive behaviour of certain commands (e.g. "git checkout"
+ and "git diff"), but currently we haven't agreed on what that
+ mechanism should look like. Therefore, if you use submodules,
+ you would probably need "git submodule update" on the
+ submodules you care about after running a "git checkout" at
+ the supermodule level.
+
* There are a handful pack-objects changes to help you cope better
with repositories with pathologically large blobs in them.
^ permalink raw reply related
* Re: resumable git-clone?
From: Johannes Schindelin @ 2007-08-08 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <7vlkcl4zcw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 8 Aug 2007, Junio C Hamano wrote:
> So I've been thinking about teaching the server side, when responding to
> a fetch request, to be able to say something like "Sorry but this
> repository is for fetching by people who have at least these commits
> from that other project I am a fork of." We make that "at least these
> from that other project" part machine readable, and git-fetch request
> git-clone makes can redirect itself to fill the prerequisites before
> attempting to go there again.
Something like the alternates that http transport can use?
> *1* Sheesh. While I was writing this I noticed that the current
> 'git bundle' is suitable only for incremental sneakernet but
> not for this particular use case.
>
> $ git bundle create 2612.bndl v2.6.12
>
> does not work, although
>
> $ git bundle create 2612-2613.bndl v2.6.12..v2.6.13
>
> does. We need to fix this.
Yes, I noticed this a long time ago. Time is lacking...
Ciao,
Dscho
^ permalink raw reply
* Re: Git'ing a non-labeled set of sources
From: Peter Baumann @ 2007-08-08 19:37 UTC (permalink / raw)
To: Sparks, Sam; +Cc: git
In-Reply-To: <CF7E46FCFF66AD478BB72724345289EC170CE4@twx-exch01.twacs.local>
On Wed, Aug 08, 2007 at 01:59:38PM -0500, Sparks, Sam wrote:
> Hello All,
>
> Please excuse me if this is an ignorant question; I'm new to git and my
> have overlooked something in the documentation.
>
> I'm attempting to obtain a snapshot of source code from an unlabeled git
> branch in a public repository. I've found in the documentation that a
> timestamp cannot be used to specify a particular version of source code,
> but I believe I can work with the commit value as returned by 'git
> show'.
>
> However, I have been unsuccessful in my attempts to use this identifier
> to clone or checkout the associated source tree. Has anyone been
> successful in using git to successfully replicate an unlabeled version
> of sources in a repository?
>
> Here is my latest attempt:
> /dir_i_want_to_replicate $ git show --pretty=short
> commit 5b1313fb2758ffce8b624457f777d8cc6709608d
> Author: ....
>
> /replication_dir $ git clone git://www.denx.de/git/u-boot.git
> u-boot-mpc83xx
> Blah blah blah..
> 100% (4378/4378) done
> /replication_dir/u-boot-mpc83xx/ $ git checkout
> 5b1313fb2758ffce8b624457f777d8cc6709608d
> error: pathspec '5b1313fb2758ffce8b624457f777d8cc6709608d' did not match
> any.
>
Because there is no 5b1313fb2758ffce8b624457f777d8cc6709608d in the
repo.
$ git clone git://www.denx.de/git/u-boot.git
Initialized empty Git repository in /tmp/u-boot/.git/
remote: Generating pack...
remote: Done counting 40938 objects.
remote: Deltifying 40938 objects.
remote: 100% (40938/40938) done
Indexing 40938 objects...
remote: Total 40938 (delta 32545), reused 39302 (delta 31040)
100% (40938/40938) done
Resolving 32545 deltas...
100% (32545/32545) done
$ cd u-boot; git-rev-list --all|grep ^5b1
5b1d713721c3ea02549940133f09236783dda1f9
-Peter
^ permalink raw reply
* Re: git-write-tree strangeness
From: Junio C Hamano @ 2007-08-08 19:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: Steven Walter, git
In-Reply-To: <81b0412b0708080910u3aee166fo92ea73a4a0a78ccf@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 8/8/07, Steven Walter <stevenrwalter@gmail.com> wrote:
>> I'm importing a large repository from svn into git with a custom tool,
>> and I noticed a strange issue with one of the commits.
>>
>> Upon investigating further, I found that when I ran "git-write-tree"
>> followed immediately by "git-diff-index <tree>" I had differences. Does
>> that mean that git-write-tree incorrectly recorded the index, or do I
>> misunderstand things?
>
> What kind of differences? Different sha1 of content?
> I can't simply reproduce it.
Isn't this simply just a dirty worktree and missing --cached
option?
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-08 19:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Mark Levedahl, Junio C Hamano, Linus Torvalds, Git Mailing List,
Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <Pine.LNX.4.64.0708081810130.14781@racer.site>
On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:
> On Wed, 8 Aug 2007, Mark Levedahl wrote:
>
>> On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>
>>> The bottom line for me is, git does not yet support Windows in a
>>> usable way for the organizations that I need to convince.
>>>
>>> Steffen
>>>
>>
>> Have you considered jumping in to help on the msys git port Johannes
>> Schindelin is working? He has very generously offered to do
>> essentially everything except find bugs, the latter because he does
>> not actually use Windows so can't, and is clearly putting a great
>> deal
>> of effort into this. A stable and complete Windows port may be much
>> closer than you think.
>
I'll look into it. However, my situation is similar to Johannes'. I do
not regularly work on Windows. I use my Mac for all office work and
typically code on Linux. However, I do use Windows from time to time
because the majority of the people I work with use Windows.
I have a real Windows running in a Virtual Machine and I consider
switching to it for a while, to see if things run smoothly. Here is
what I plan to do: I will set cygwin to textmode (!), although I know
better. But this is what most of the people I work with have. I'll
uninstall cygwin's git and install msysgit instead. I'll try to do
all the integration work, that is import from cvs on Linux, pull to
Windows and do coding and merges on Windows. I'll push back to Linux
and Mac for testing.
After the basic stuff, like pull, push, merge, commit, gitk, and
git gui, here's my first more difficult task: Will git-mergetool
launch something useful for me on Windows? I heard that WinDiff
would be useful. On Mac I use FileMerge.
> To be fair, we are already a team of five working on it. The 3rd
> generation of the net installer works as flawlessly as the first, but
> msysgit.git is a superproject now, containing the complete build
> environment you need, and has git/mingw/4msysgit.git as a submodule
> (yes,
> that is a fork of a fork; they work now on repo.or.cz).
>
> Please find it on
>
> http://msysgit.googlecode.com/
>
> (It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It
> already passes all tests, is able to start gitk and git-gui, and
> more is
> to come!
>
> And no, I did not agree to do _everything_. I agreed to do things
> _when I
> get something in return_.
I read this before. At the time you wrote about this on the mailing list
I thought that cygwin would be fine. I wasn't aware of the binmode/
textmode
magic and all the problems caused by it.
> For example, we have a functional script sitting in msysgit.git which
> builds a complete WinGit installer (WinGit being the code name for
> "Git on
> MSys without the whole build environment").
>
> It is incomplete in only a few issues:
>
> - it does not install anything in the start menu
>
> - it does not install any short cut on the Desktop
>
> - it does not install anything in the Quick Launch bar
>
> - it does not include a nice WelcomeToGit.html, to be launched
> after a successful install
>
> - it does not contain a nice way to start git-gui (you have to
> start it by hand from the command line inside bash)
>
> - etc.
>
> So go for it, everybody, or alternatively do not even bother to whine.
I don't care about these things. I typically start the Explorer by
typing
explorer into the 'Run ...' box of the start meny. So don't expect
anything
from me that makes git more beautiful.
The only thing I want to achieve is a flawlessly running git that works
out-of-the box in the presence of a cygwin in textmode (!). If possible
git should have the same version number that I have on Linux and Mac,
which means the master branch of Junio's repo on my Mac. Lagging a bit
behind for a while is ok, but in general I'd prefer to have the same
version on Linux, Mac, and Windows. What I described means Windows
support
for me. Having a nice installer is not important.
> Ciao,
> Dscho
>
> P.S.: I'll be not really available for a few days, starting from
> tomorrow,
> so do use the mailing list to keep in touch with others working on
> msysgit
> or 4msysgit, and do use the mob branch (you can bug the project
> members
> listed on the homepage to cherry-pick, sign off and push if need be).
>
ok. I'll be available for one more week and will then be offline
for three weeks.
Steffen
^ permalink raw reply
* Re: Submodules
From: Johannes Schindelin @ 2007-08-08 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Dmitry Kakurin, git
In-Reply-To: <7vhcn94y9l.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 8 Aug 2007, Junio C Hamano wrote:
> + Note that the current submodule support is minimal and this is
> + deliberately so. A design decision we made is that operations
> + at the supermodule level do not recurse into submodules by
> + default. The expectation is that later we would add a
> + mechanism to tell git which submodules the user is interested
> + in, and this information might be used to determine the
> + recursive behaviour of certain commands (e.g. "git checkout"
> + and "git diff"), but currently we haven't agreed on what that
> + mechanism should look like. Therefore, if you use submodules,
> + you would probably need "git submodule update" on the
> + submodules you care about after running a "git checkout" at
> + the supermodule level.
> +
Nice write up!
Is it true that you can run "update" without "init" first? (I haven't
tried yet.)
Also, I realised that git is not really happy unless you install
alternates pointing to the object stores of the submodules. Shouldn't we
make this my default (for example in "init")?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: Johannes Schindelin @ 2007-08-08 19:42 UTC (permalink / raw)
To: Alexandre Bourget; +Cc: Git Mailing List, paulus
In-Reply-To: <1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com>
Hi,
On Wed, 8 Aug 2007, Alexandre Bourget wrote:
> ---
> Adds a context menu for commits, so that a 'rebase' can be done.
>
> Optionally, it will ask if you want to 'stash' current work before doing so.
>
You want something like this as a commit message, _not_ between "---" and
diffstat.
General question: should this not be in git-gui rather than gitk? Gitk as
of now is really more a viewing tool.
Ciao,
Dscho
^ permalink raw reply
* RE: Git'ing a non-labeled set of sources
From: Sparks, Sam @ 2007-08-08 19:52 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20070808193720.GD27470@xp.machine.xx>
>-----Original Message-----
>From: Peter Baumann [mailto:waste.manager@gmx.de]
>Sent: Wednesday, August 08, 2007 2:37 PM
>To: Sparks, Sam
>Cc: git@vger.kernel.org
>Subject: Re: Git'ing a non-labeled set of sources
>
>On Wed, Aug 08, 2007 at 01:59:38PM -0500, Sparks, Sam wrote:
>> Hello All,
>>
>> Please excuse me if this is an ignorant question; I'm new to
>git and my
>> have overlooked something in the documentation.
>>
>> I'm attempting to obtain a snapshot of source code from an
>unlabeled git
>> branch in a public repository. I've found in the documentation that a
>> timestamp cannot be used to specify a particular version of
>source code,
>> but I believe I can work with the commit value as returned by 'git
>> show'.
>>
>> However, I have been unsuccessful in my attempts to use this
>identifier
>> to clone or checkout the associated source tree. Has anyone been
>> successful in using git to successfully replicate an
>unlabeled version
>> of sources in a repository?
>>
>> Here is my latest attempt:
>> /dir_i_want_to_replicate $ git show --pretty=short
>> commit 5b1313fb2758ffce8b624457f777d8cc6709608d
>> Author: ....
>>
>> /replication_dir $ git clone git://www.denx.de/git/u-boot.git
>> u-boot-mpc83xx
>> Blah blah blah..
>> 100% (4378/4378) done
>> /replication_dir/u-boot-mpc83xx/ $ git checkout
>> 5b1313fb2758ffce8b624457f777d8cc6709608d
>> error: pathspec '5b1313fb2758ffce8b624457f777d8cc6709608d'
>did not match
>> any.
>>
>
>Because there is no 5b1313fb2758ffce8b624457f777d8cc6709608d in the
>repo.
>
> $ git clone git://www.denx.de/git/u-boot.git
> Initialized empty Git repository in /tmp/u-boot/.git/
> remote: Generating pack...
> remote: Done counting 40938 objects.
> remote: Deltifying 40938 objects.
> remote: 100% (40938/40938) done
> Indexing 40938 objects...
> remote: Total 40938 (delta 32545), reused 39302 (delta 31040)
> 100% (40938/40938) done
> Resolving 32545 deltas...
> 100% (32545/32545) done
>
> $ cd u-boot; git-rev-list --all|grep ^5b1
> 5b1d713721c3ea02549940133f09236783dda1f9
>
>-Peter
Hmmm. There must be something I am not understanding about git.
When I run the same command on my existing git repository, I get the
following:
$ git-rev-list --all | grep ^5b1
5b1313fb2758ffce8b624457f777d8cc6709608d
5b1d713721c3ea02549940133f09236783dda1f9
Does git allow the removal of commits? I don't understand how I was able
to download it a couple of months ago, but it is no longer accessible.
Thanks for the quick reply,
Sam
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: Junio C Hamano @ 2007-08-08 19:53 UTC (permalink / raw)
To: Alexandre Bourget; +Cc: Git Mailing List, paulus
In-Reply-To: <1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com>
Alexandre Bourget <alexandre.bourget@savoirfairelinux.com>
writes:
> ---
> Adds a context menu for commits, so that a 'rebase' can be done.
>
> Optionally, it will ask if you want to 'stash' current work before doing so.
>
> TODO: better error handling.
Please do not discard a commit log message by placing them after
the three-dashes. A good commit message would be of this form:
- A single line to summarize what it does (goes to Subject);
- A blank line (paragraph break);
- A paragraph or more that elaborate on the above summary, if
needed, and defend why the change is a good idea; especially
if you considered other alternatives, a comparison to justify
your choice.
This is largely up to Paulus, but I think anything that
updates the repository should go to git-gui, not gitk. The
latter is primarily a viewer.
^ permalink raw reply
* Re: Submodules
From: Sven Verdoolaege @ 2007-08-08 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Kakurin, Johannes Schindelin, git
In-Reply-To: <7vhcn94y9l.fsf@assigned-by-dhcp.cox.net>
On Wed, Aug 08, 2007 at 12:33:26PM -0700, Junio C Hamano wrote:
> + Note that the current submodule support is minimal and this is
> + deliberately so. A design decision we made is that operations
> + at the supermodule level do not recurse into submodules by
> + default. The expectation is that later we would add a
> + mechanism to tell git which submodules the user is interested
> + in, and this information might be used to determine the
> + recursive behaviour of certain commands (e.g. "git checkout"
> + and "git diff"), but currently we haven't agreed on what that
> + mechanism should look like. Therefore, if you use submodules,
> + you would probably need "git submodule update" on the
> + submodules you care about after running a "git checkout" at
> + the supermodule level.
> +
Maybe you could be a bit more explicit about the
possibly unexpected results of "git checkout".
Perhaps something like the following instead of the
last sentence:
In particular, if you have any submodules checked out,
running a "git checkout" at the supermodule level will
not update these submodules. They will therefore appear
to be modified (to the state prior to the checkout)
to any subsequent git command, until they have been
updated explicitly using "git submodule update".
skimo
^ permalink raw reply
* Re: Submodules
From: Junio C Hamano @ 2007-08-08 19:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708082138520.21916@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 8 Aug 2007, Junio C Hamano wrote:
>
>> + Note that the current submodule support is minimal and this is
>> + deliberately so. A design decision we made is that operations
>> + at the supermodule level do not recurse into submodules by
>> + default. The expectation is that later we would add a
>> + mechanism to tell git which submodules the user is interested
>> + in, and this information might be used to determine the
>> + recursive behaviour of certain commands (e.g. "git checkout"
>> + and "git diff"), but currently we haven't agreed on what that
>> + mechanism should look like. Therefore, if you use submodules,
>> + you would probably need "git submodule update" on the
>> + submodules you care about after running a "git checkout" at
>> + the supermodule level.
>> +
>
> Nice write up!
>
> Is it true that you can run "update" without "init" first? (I haven't
> tried yet.)
>
> Also, I realised that git is not really happy unless you install
> alternates pointing to the object stores of the submodules. Shouldn't we
> make this my default (for example in "init")?
Sorry, but I do not use submodules yet myself. The questions
need to be answered, errors need to be corrected and omissions
need to be added by people who have been more involved in that
area of the system.
That's would be Sven and Lars, probably.
I also think we should have a paragraph of similar spirit
about the work-tree stuff as the top-level bullet point, before
the "New commands and options" list. I suspect Matthias and you
are the prime candidates to do the honors?
^ permalink raw reply
* Re: Submodules
From: Sven Verdoolaege @ 2007-08-08 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <7vps1x3ihp.fsf@assigned-by-dhcp.cox.net>
On Wed, Aug 08, 2007 at 12:59:30PM -0700, Junio C Hamano wrote:
> Sorry, but I do not use submodules yet myself.
If you would ever start using submodules (for, say, gitgui),
then I'm sure we'd have much more usable submodules support
in no time.
skimo
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: David Kastrup @ 2007-08-08 20:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexandre Bourget, Git Mailing List, paulus
In-Reply-To: <Pine.LNX.4.64.0708082141170.21916@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 8 Aug 2007, Alexandre Bourget wrote:
>
>> ---
>> Adds a context menu for commits, so that a 'rebase' can be done.
>>
>> Optionally, it will ask if you want to 'stash' current work before doing so.
>>
>
> You want something like this as a commit message, _not_ between "---" and
> diffstat.
>
> General question: should this not be in git-gui rather than gitk? Gitk as
> of now is really more a viewing tool.
Well, yes. But git-gui only works on a single branch head at a time,
and that is not enough for rebasing. It would be really nice if
git-gui did not outsource its branch handling and viewing to gitk.
Could git-gui perhaps be merged with giggle at some point of time?
Another option might be to let it talk with uDraw(Graph) over a
socket: uDraw(Graph) keeps track of the graph layout and tells its
client what has been dragged where.
Rebasing would also be a fine operation for drag and drop on a
graphical revision history/branch system: pull one head onto another,
or mark one segment and pull it onto another head. And use the reflog
to recover from catastrophes...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-08 20:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Mark Levedahl, Junio C Hamano, Linus Torvalds, Git Mailing List,
Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <75EB313E-807D-44FB-A186-A151F182B47B@zib.de>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On Aug 8, 2007, at 9:37 PM, Steffen Prohaska wrote:
> I have a real Windows running in a Virtual Machine and I consider
> switching to it for a while, to see if things run smoothly. Here is
> what I plan to do: I will set cygwin to textmode (!), although I know
> better. But this is what most of the people I work with have. I'll
> uninstall cygwin's git and install msysgit instead. I'll try to do
> all the integration work, that is import from cvs on Linux, pull to
> Windows and do coding and merges on Windows. I'll push back to Linux
> and Mac for testing.
Here we go... I tried GitMe-3.exe.
I have two 'crashes' during installation. I attached snapshots
of the requesters. I don't know how to copy text from the
installer. Therefore I attached snapshots.
As mentioned before, I run in a virtual machine, Parallels to be exact.
I use my Windows installation rarely but I did not have any problems
with Windows in Parallels before.
Steffen
[-- Attachment #2.1: requester1.png --]
[-- Type: application/applefile, Size: 74 bytes --]
[-- Attachment #2.2: requester1.png --]
[-- Type: image/png, Size: 8529 bytes --]
[-- Attachment #3.1: output2.png --]
[-- Type: application/applefile, Size: 71 bytes --]
[-- Attachment #3.2: output2.png --]
[-- Type: image/png, Size: 18058 bytes --]
[-- Attachment #4.1: requester2.png --]
[-- Type: application/applefile, Size: 74 bytes --]
[-- Attachment #4.2: requester2.png --]
[-- Type: image/png, Size: 8513 bytes --]
[-- Attachment #5: Type: text/plain, Size: 1 bytes --]
[-- Attachment #6.1: result.png --]
[-- Type: application/applefile, Size: 70 bytes --]
[-- Attachment #6.2: result.png --]
[-- Type: image/png, Size: 10023 bytes --]
^ 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