* 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
* Re: Git'ing a non-labeled set of sources
From: Peter Baumann @ 2007-08-08 20:17 UTC (permalink / raw)
To: Sparks, Sam; +Cc: git
In-Reply-To: <CF7E46FCFF66AD478BB72724345289EC170CE5@twx-exch01.twacs.local>
On Wed, Aug 08, 2007 at 02:52:14PM -0500, Sparks, Sam wrote:
>
>
> >-----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
If the branch was rebased, then yes. But this is not nice for
contributers, so it is normally the rule to not rebase a published
branch. But e.g. the branch 'pu' on git.git is a branch which will be
rebased. This is mentioned by Junio in his notes from the maintainer.
What made me wonder is, if you have the commit localy, why can't you
check it out? Please try a git-fsck --full run, to see if you have a
corrupt repo.
-Peter
^ permalink raw reply
* Re: Submodules
From: Junio C Hamano @ 2007-08-08 20:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, Dmitry Kakurin, git
In-Reply-To: <7vps1x3ihp.fsf@assigned-by-dhcp.cox.net>
Ok, this is my second try.
- Incorporated Sven's suggestion to give an example of
problematic situation on submodule after "git-checkout" at
the supermodule level;
- Describe semantic clean-up of specifying GIT_DIR that is
not strictly needed (because it is situated at the normal
place relative to the working tree).
---
diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt
index 21bb1fc..bf7a341 100644
--- a/Documentation/RelNotes-1.5.3.txt
+++ b/Documentation/RelNotes-1.5.3.txt
@@ -9,6 +9,40 @@ 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. 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".
+
+* You can have a work tree not at the parent directory of .git
+ which is the repository. This is done with GIT_WORK_TREE
+ environment, or --work-tree option.
+
+ This support slightly changes the semantics of having GIT_DIR
+ environment variable. The rule used to be that when it is
+ given, you are supposed to be at the top level of the working
+ tree. However, if it names a .git directory at the top of the
+ working tree, you can be in a subdirectory of that directory
+ and git notices you are in the subdirectory. E.g. in t/
+ subdirectory of git.git project,
+
+ $ cd t
+ $ GIT_DIR=../.git/ git ls-files -s
+
+ will list the files in t/ (i.e. your current directory). It
+ used not to notice that you are in a subdirectory and listed
+ the files from the top-level of the working tree.
+
* 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: [PATCH] cmd-list.perl: Alphabetize command list
From: Junio C Hamano @ 2007-08-08 20:34 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: git mailing list, Junio C Hamano
In-Reply-To: <588192970708081230y76520dak857261e96eae317a@mail.gmail.com>
"Steve Hoelzer" <shoelzer@gmail.com> writes:
> Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Applying cmd-list.perl: Alphabetize command list
fatal: corrupt patch at line 10
Patch failed at 0001.
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-08 20:36 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: <2F00D32E-8D0C-48D6-86E1-6F6E7611E364@zib.de>
On Aug 8, 2007, at 10:13 PM, Steffen Prohaska wrote:
> 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.
Hmm... how do I get started? I naively chose cygwin as my
shell. I set
export PATH=$PATH:/cygdrive/c/msysgit/bin
then I tried
$ git clone git://git.kernel.org/pub/scm/git/git.git
c:/msysgit/bin/git-clone: line 214: git-init: command not found
Maybe it's related to the errors during installation?
How can I build and install git manually, based on the result
of GitMe-3's basic setup?
Steffen
^ permalink raw reply
* Re: [PATCH] cmd-list.perl: Alphabetize command list
From: Junio C Hamano @ 2007-08-08 20:44 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: git mailing list
In-Reply-To: <588192970708081230y76520dak857261e96eae317a@mail.gmail.com>
I'll commit this instead. It does not match your patch, but I
think this is more logical.
-- >8 --
Reorder the list of commands in the manual.
The basic idea was proposed by Steve Hoelzer; in order to make
the list easier to search, we keep the command list in the
script that generates it with "sort -d".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 2143995..4ee76ea 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -68,6 +68,8 @@ for my $cat (qw(ancillaryinterrogators
}
}
+# The following list is sorted with "sort -d" to make it easier
+# to find entry in the resulting git.html manual page.
__DATA__
git-add mainporcelain
git-am mainporcelain
@@ -80,9 +82,9 @@ 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-checkout mainporcelain
+git-checkout-index plumbingmanipulators
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
@@ -91,6 +93,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 +101,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
@@ -130,13 +133,13 @@ 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
+git-merge-tree ancillaryinterrogators
git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
git-mv mainporcelain
@@ -157,9 +160,8 @@ 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
^ permalink raw reply related
* RE: Git'ing a non-labeled set of sources
From: Sparks, Sam @ 2007-08-08 20:45 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20070808201718.GE27470@xp.machine.xx>
>-----Original Message-----
>From: Peter Baumann [mailto:waste.manager@gmx.de]
>Sent: Wednesday, August 08, 2007 3:17 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 02:52:14PM -0500, Sparks, Sam wrote:
>>
>>
>> >-----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
>
>If the branch was rebased, then yes. But this is not nice for
>contributers, so it is normally the rule to not rebase a published
>branch. But e.g. the branch 'pu' on git.git is a branch which will be
>rebased. This is mentioned by Junio in his notes from the maintainer.
>
>What made me wonder is, if you have the commit localy, why can't you
>check it out? Please try a git-fsck --full run, to see if you have a
>corrupt repo.
>
>-Peter
>
>
I had to upgrade from git v1.4.4.4 to v1.5.0.7 to have access to the
git-fsck command. 'git-fsck --full' printed out nothing, and 'git-fsck
--full run' printed out an error message (error: invalid parameter:
expected sha1, got 'run'). Was I doing something wrong?
--Sam
^ permalink raw reply
* Re: Submodules
From: Andy Parkins @ 2007-08-08 20:47 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, skimo, Dmitry Kakurin
In-Reply-To: <Pine.LNX.4.64.0708082138520.21916@wbgn129.biozentrum.uni-wuerzburg.de>
On Wednesday 2007, August 08, Johannes Schindelin wrote:
> 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")?
I use submodules on a daily basis and haven't experienced this at all.
Would you mind saying a little more about this problem?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git-svn: Finding the svn-URL of the current branch in git
From: Peter Baumann @ 2007-08-08 20:57 UTC (permalink / raw)
To: Matthias Kleine, git
In-Reply-To: <20070808192537.GB27470@xp.machine.xx>
On Wed, Aug 08, 2007 at 09:25:37PM +0200, Peter Baumann wrote:
> 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
^- should, because both cases aren't
implemented yet.
> 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
* RE: Git'ing a non-labeled set of sources
From: Sparks, Sam @ 2007-08-08 20:59 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <CF7E46FCFF66AD478BB72724345289EC170CE6@twx-exch01.twacs.local>
>-----Original Message-----
>From: Sparks, Sam
>Sent: Wednesday, August 08, 2007 3:46 PM
>To: Peter Baumann
>Cc: git@vger.kernel.org
>Subject: RE: Git'ing a non-labeled set of sources
>
>
>
>>-----Original Message-----
>>From: Peter Baumann [mailto:waste.manager@gmx.de]
>>Sent: Wednesday, August 08, 2007 3:17 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 02:52:14PM -0500, Sparks, Sam wrote:
>>>
>>>
>>> >-----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
>>
>>If the branch was rebased, then yes. But this is not nice for
>>contributers, so it is normally the rule to not rebase a published
>>branch. But e.g. the branch 'pu' on git.git is a branch which will be
>>rebased. This is mentioned by Junio in his notes from the maintainer.
>>
>>What made me wonder is, if you have the commit localy, why can't you
>>check it out? Please try a git-fsck --full run, to see if you have a
>>corrupt repo.
>>
>>-Peter
>>
>>
>I had to upgrade from git v1.4.4.4 to v1.5.0.7 to have access
>to the git-fsck command. 'git-fsck --full' printed out
>nothing, and 'git-fsck --full run' printed out an error
>message (error: invalid parameter: expected sha1, got 'run').
>Was I doing something wrong?
>
>--Sam
Peter,
I had an epiphany and discovered the problem: When I created the
repository I was trying to replicate, I didn't download it using git; I
simply copied it from another u-boot repository on the same server.
When trying to use the commit number on a known good build, I didn't
have any problem replicating that branch.
Thanks for the help, and sorry it was a dumb error on my part.
--Sam
^ permalink raw reply
* [PATCH] checkout_entry: only try to create directories when no file existed there
From: Johannes Schindelin @ 2007-08-08 21:00 UTC (permalink / raw)
To: gitster, git
It is obvious that we do not have to create directories when the file we
want to check out already existed.
Besides, it fixes the obscure use case, where you want to track a file which
is _outside_ of your working tree, by creating a symbolic link to the directory
it lives in, and adding the file with something like "git add symlink/file".
Without this patch, "git checkout symlink/file" would actually _replace_
"symlink" by a directory of the same name.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
entry.c | 8 +++++---
t/t2007-checkout-symlink.sh | 11 +++++++++++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index 0625112..eacdba2 100644
--- a/entry.c
+++ b/entry.c
@@ -223,8 +223,10 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
return error("%s is a directory", path);
remove_subtree(path);
}
- } else if (state->not_new)
- return 0;
- create_directories(path, state);
+ } else {
+ if (state->not_new)
+ return 0;
+ create_directories(path, state);
+ }
return write_entry(ce, path, state, 0);
}
diff --git a/t/t2007-checkout-symlink.sh b/t/t2007-checkout-symlink.sh
index 0526fce..02224eb 100755
--- a/t/t2007-checkout-symlink.sh
+++ b/t/t2007-checkout-symlink.sh
@@ -47,4 +47,15 @@ test_expect_success 'switch from dir to symlink' '
'
+test_expect_success 'checkout does not replace symlink/file with dir/file' '
+ mkdir 123 &&
+ ln -s 123 abc &&
+ echo 1 > abc/1 &&
+ echo 2 > abc/2 &&
+ echo 3 > abc/3 &&
+ git add abc/? &&
+ echo 0 > abc/3 &&
+ git checkout abc/3 &&
+ test -h abc
+'
test_done
--
1.5.3.rc4.26.g782e
^ permalink raw reply related
* Re: [PATCH] Further changes, thanks to <tp@lists.linux.it>
From: Michael @ 2007-08-08 21:04 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi
In-Reply-To: <20070808172739.5647a81b@paolo-desktop>
On Wednesday 08 August 2007 17:27, Paolo Ciarrocchi wrote:
> Further changes, thanks to <tp@lists.linux.it>
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
> ---
Is it just me, or this patch is corrupted?
> po/it.po | 130
> ++++++++++++++++++++++++++++++++------------------------------ 1 files
> changed, 67 insertions(+), 63 deletions(-)
git-am says:
Applying Further changes, thanks to <tp@lists.linux.it>
fatal: corrupt patch at line 13
Patch failed at 0001.
git-gui-i18n$ grep ^- .dotest/0001 | wc
66 434 3074
git-gui-i18n$ grep ^+ .dotest/0001 | wc
27 105 955
I think there's a problem somewhere...
> diff --git a/po/it.po b/po/it.po
> index e87263e..1950b56 100644
> --- a/po/it.po
> +++ b/po/it.po
> @@ -2,18 +2,21 @@
> # Copyright (C) 2007 Shawn Pearce
> # This file is distributed under the same license as the git-gui
> package. # Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>, 2007
Whitespace/newline corruption?
> -"Content-Type: text/plain; charset=UTF-8\n"
> -"Content-Transfer-Encoding: 8bit\n"
> +"Content-Type: text/plain; charset=iso-8859-1\n"
> +"Content-Transfer-Encoding: 8bit"
I'd guess the previous version is better :)
> @@ -34,9 +37,9 @@ msgid ""
> "\n"
> "Assume '%s' is version 1.5.0?\n"
> msgstr ""
> -"La versione di GIT non può essere determinata.\n"
> "\n"
> -"%s sostiene che la versione è '%s'.\n"
> "\n"
> "%s richiede almeno Git 1.5.0 o superiore.\n"
> "\n"
Here and in many other places there are unneeded deletions... Is
that what you wanted? I don't think so, since the hunk header says
"@@ -34,9 +37,9 @@". I guess gmail has done a mess with your
patch: git-am had some problems parsing the headers too.
You should try to mail the same patch to yourself and re-apply that on
your tree to see if it fails.
^ permalink raw reply
* Workflow question: A case for git-rebase?
From: Thomas Adam @ 2007-08-08 21:11 UTC (permalink / raw)
To: git
Hello all,
So we've (as in my place of work) have switched from SVN to GIT
although I do have a few questions -- hopefully they're not too
obvious. :)
We have our master branch which is where all the latest changes are
added to as a "remote shared repository which everyone pushes and
pulls to. That's emulating pretty much what SVN did -- which is
fine.
As for myself, I maintain _locally_ a few branches (branchX, branchY)
which dictate some bits and pieces I'm working on. Periodically, I
will tend to merge either merge to master and then push those changes
out. So far so good...
But, I've now come up against a case whereby if one of my colleagues
changes a file (call it fileA) in branch master, and, in the course of
my working in branchX means i modify fileA also, when I come to merge
branchX into master I find the original change in master (as submitted
by my colleague) being reverted by my changes in branchX. Luckily I
don't commit that since I do a git-diff beforehand. :)
One suggest solution to this is to merge master into branchX/branchY
periodically, although this has the same problems as described when I
try to merge -- if I'm going to make branchX the same as master, I
might as well just work in master and be done with it, right?
So I was wondering if it's fine to branch from master at any given
point and perhaps use git-rebasse when I come to merge? Is this even
the correct mode of working? Indeed, there might be times when
git-rebase isn't necessary if a merge to master from branchX or
branchY won't revert a commit in master because that file had been
edited, so how do I determine when to use git-rebase in this case? Or
is that the correct indicator?
I do hope that makes sense.
Kindly,
Thomas Adam
^ permalink raw reply
* Re: Submodules
From: Johannes Schindelin @ 2007-08-08 21:12 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano, skimo, Dmitry Kakurin
In-Reply-To: <200708082147.57822.andyparkins@gmail.com>
Hi,
On Wed, 8 Aug 2007, Andy Parkins wrote:
> On Wednesday 2007, August 08, Johannes Schindelin wrote:
>
> > 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")?
>
> I use submodules on a daily basis and haven't experienced this at all.
> Would you mind saying a little more about this problem?
Not at all!
This is what I did. I cloned msysgit.git, which contains one submodule.
To initialise that, I did "git submodule init" and "git submodule update".
It went and cloned the submodule. Fine.
Then I committed in the submodule, a well-needed fix.
If I now go to the superproject again, and say "git submodule status", it
will not find the newest commit, and complain that it cannot access that
object.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] checkout_entry: only try to create directories when no file existed there
From: Junio C Hamano @ 2007-08-08 21:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708082200240.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is obvious that we do not have to create directories when the file we
> want to check out already existed.
It is not so obvious to me. In fact I vaguely recall we had
complaint about opposite case where we did not honor a symlink
to be checked out as a symlink because an earlier branch had it
as a directory.
^ permalink raw reply
* Re: Git'ing a non-labeled set of sources
From: Alex Riesen @ 2007-08-08 21:20 UTC (permalink / raw)
To: Sparks, Sam; +Cc: Peter Baumann, git
In-Reply-To: <CF7E46FCFF66AD478BB72724345289EC170CE5@twx-exch01.twacs.local>
Sparks, Sam, Wed, Aug 08, 2007 21:52:14 +0200:
> >From: Peter Baumann [mailto:waste.manager@gmx.de]
> >
> >Because there is no 5b1313fb2758ffce8b624457f777d8cc6709608d in the
> >repo.
>
> 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.
They cleaned up. Rebased or discarded the branch which had the commit
and cleaned up. That's what "git gc" and "git prune" do.
^ permalink raw reply
* Re: [PATCH] checkout_entry: only try to create directories when no file existed there
From: David Kastrup @ 2007-08-08 21:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0708082200240.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is obvious that we do not have to create directories when the file we
> want to check out already existed.
>
> Besides, it fixes the obscure use case, where you want to track a
> file which is _outside_ of your working tree, by creating a symbolic
> link to the directory it lives in, and adding the file with
> something like "git add symlink/file". Without this patch, "git
> checkout symlink/file" would actually _replace_ "symlink" by a
> directory of the same name.
Uh, when git is tracking symlinks (and it does by default), this is
quite the correct thing to do. Of course, it should rather barf with
a merge conflict. But it has no business following links and doing
potential damage either outside or inside of the work tree, by
confusing the target of a link with the link itself. For example, I
can easily relocate a complete git work tree with "mv" in the
directory hierarchy. Should an update/commit/whatever then start
wreaking havoc in places that incidentally don't point to the same
location anymore?
My vote here is emphatically "no". Just maintain the links, not
whatever they point to.
I can think of only a single reasonable exception: if the symlink
itself is _not_ registered (because is has been explicitly entered
into a .gitignore file or never added for other reasons), but its
target _has_ been added explicitly _dereferencing_ the symlink. This
difference can only occur with directory symlinks since file symlinks
can't be distinguished in this manner from the name of the link
itself.
It would be good if somebody brought this to Johannes' attention, even
if just replying with a quotation: he chose to killfile me.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Johannes Schindelin @ 2007-08-08 21:30 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <75EB313E-807D-44FB-A186-A151F182B47B@zib.de>
Hi,
On Wed, 8 Aug 2007, Steffen Prohaska wrote:
> On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:
>
> > 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.
That's nice to hear. Finally somebody honest. I'll return the favour: I
have no time to work on the bugs you sent in a reply.
Ciao,
Dscho
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Karl Hasselström @ 2007-08-08 21:39 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070808092027.GB7860@diana.vm.bytemark.co.uk>
On 2007-08-08 11:20:27 +0200, Karl Hasselström wrote:
> On 2007-08-08 01:03:53 -0400, Pavel Roskin wrote:
>
> > Also, "stg import" commits the patch, which seems wrong to me.
>
> Hmm, I hadn't noticed. That would be an unintended side-effect of
> the DAG patches, presumably. I'll look into it tonight.
I can't reproduce. (Using master of git://repo.or.cz/stgit/kha.git.)
The last subtest of t1800 actually tests that a mailbox was imported
as a series of patches, and that works fine for me (the other subtests
don't make sure that a patch was created; they just verify that we got
the right tree). Furthermore, the following works for me:
kha@yoghurt:~/stgit/t> ./t1800-import.sh
* ok 1: Initialize the StGIT repository
* ok 2: Apply a patch created with "git diff"
* ok 3: Apply a patch created with GNU diff
* ok 4: Apply a patch created with "stg export"
* ok 5: Apply a patch from an 8bit-encoded e-mail
* ok 6: Apply a patch from a QP-encoded e-mail
* ok 7: Apply several patches from an mbox file
* passed all 7 test(s)
kha@yoghurt:~/stgit/t> cd trash/
kha@yoghurt:~/stgit/t/trash> ls
foo.txt
kha@yoghurt:~/stgit/t/trash> PATH=/home/kha/stgit:$PATH stg series -d
kha@yoghurt:~/stgit/t/trash> PATH=/home/kha/stgit:$PATH stg import -m ../t1800-import/email-qp
Checking for changes in the working directory ... done
Finding uninteresting commits ... done
Importing patch "email-qp" ... done
Now at patch "email-qp"
kha@yoghurt:~/stgit/t/trash> PATH=/home/kha/stgit:$PATH stg series -d
> email-qp | test patch
So a patch is definitely created. Could you describe in more detail
exactly what you do to make it fail?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] checkout_entry: only try to create directories when no file existed there
From: Johannes Schindelin @ 2007-08-08 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pj93evc.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 8 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > It is obvious that we do not have to create directories when the file we
> > want to check out already existed.
>
> It is not so obvious to me. In fact I vaguely recall we had
> complaint about opposite case where we did not honor a symlink
> to be checked out as a symlink because an earlier branch had it
> as a directory.
That case is not affected by my patch, AFAICT. It only affects the case
when you check out an entry, say "a/b/c/d/e/f/g". If that file already
exists, we have to remove it, in order to write over it. That's the
"unlink" which is above the hunk of the diff I sent.
Now, if we have to remove it, we did a stat() before that. It succeeded.
So we know that "a/b/c/d/e/f/" exists. It might contain some symlinks,
but it exists.
So putting the "create_directories()" into the else branch, we avoid doing
unnecessary work.
Coincidentally, my hackish use case (don't try this at home, kids!) is
fixed, too.
Ciao,
Dscho
^ permalink raw reply
* Re: Workflow question: A case for git-rebase?
From: Johannes Schindelin @ 2007-08-08 21:47 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0708081411p41eaa44ai105adaef0e4b10a5@mail.gmail.com>
Hi,
On Wed, 8 Aug 2007, Thomas Adam wrote:
> As for myself, I maintain _locally_ a few branches (branchX, branchY)
> which dictate some bits and pieces I'm working on. Periodically, I
> will tend to merge either merge to master and then push those changes
> out. So far so good...
>
> But, I've now come up against a case whereby if one of my colleagues
> changes a file (call it fileA) in branch master, and, in the course of
> my working in branchX means i modify fileA also, when I come to merge
> branchX into master I find the original change in master (as submitted
> by my colleague) being reverted by my changes in branchX.
I have a hard time seeing that. If you touch the same code,
unidentically, merge-recursive will not be nice to you: it will show
conflicts, and you have to resolve them.
Or do you use "-s ours"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Further changes, thanks to <tp@lists.linux.it>
From: Paolo Ciarrocchi @ 2007-08-08 21:50 UTC (permalink / raw)
To: Michael; +Cc: git
In-Reply-To: <200708082304.53867.barra_cuda@katamail.com>
On 8/8/07, Michael <barra_cuda@katamail.com> wrote:
> On Wednesday 08 August 2007 17:27, Paolo Ciarrocchi wrote:
> > Further changes, thanks to <tp@lists.linux.it>
> >
> > Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
> > ---
>
> Is it just me, or this patch is corrupted?
>
> > po/it.po | 130
> > ++++++++++++++++++++++++++++++++------------------------------ 1 files
> > changed, 67 insertions(+), 63 deletions(-)
>
> git-am says:
>
> Applying Further changes, thanks to <tp@lists.linux.it>
>
> fatal: corrupt patch at line 13
> Patch failed at 0001.
>
> git-gui-i18n$ grep ^- .dotest/0001 | wc
> 66 434 3074
> git-gui-i18n$ grep ^+ .dotest/0001 | wc
> 27 105 955
>
> I think there's a problem somewhere...
>
> > diff --git a/po/it.po b/po/it.po
> > index e87263e..1950b56 100644
> > --- a/po/it.po
> > +++ b/po/it.po
> > @@ -2,18 +2,21 @@
> > # Copyright (C) 2007 Shawn Pearce
> > # This file is distributed under the same license as the git-gui
> > package. # Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>, 2007
>
> Whitespace/newline corruption?
>
> > -"Content-Type: text/plain; charset=UTF-8\n"
> > -"Content-Transfer-Encoding: 8bit\n"
> > +"Content-Type: text/plain; charset=iso-8859-1\n"
> > +"Content-Transfer-Encoding: 8bit"
>
> I'd guess the previous version is better :)
>
> > @@ -34,9 +37,9 @@ msgid ""
> > "\n"
> > "Assume '%s' is version 1.5.0?\n"
> > msgstr ""
> > -"La versione di GIT non può essere determinata.\n"
> > "\n"
> > -"%s sostiene che la versione è '%s'.\n"
> > "\n"
> > "%s richiede almeno Git 1.5.0 o superiore.\n"
> > "\n"
>
> Here and in many other places there are unneeded deletions... Is
> that what you wanted? I don't think so, since the hunk header says
> "@@ -34,9 +37,9 @@". I guess gmail has done a mess with your
> patch: git-am had some problems parsing the headers too.
>
> You should try to mail the same patch to yourself and re-apply that on
> your tree to see if it fails.
I don't know what happened :-(
I'll redo the patch.
Thanks.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Workflow question: A case for git-rebase?
From: Thomas Adam @ 2007-08-08 21:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708082246370.21857@racer.site>
On 08/08/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 8 Aug 2007, Thomas Adam wrote:
>
> > As for myself, I maintain _locally_ a few branches (branchX, branchY)
> > which dictate some bits and pieces I'm working on. Periodically, I
> > will tend to merge either merge to master and then push those changes
> > out. So far so good...
> >
> > But, I've now come up against a case whereby if one of my colleagues
> > changes a file (call it fileA) in branch master, and, in the course of
> > my working in branchX means i modify fileA also, when I come to merge
> > branchX into master I find the original change in master (as submitted
> > by my colleague) being reverted by my changes in branchX.
>
> I have a hard time seeing that. If you touch the same code,
> unidentically, merge-recursive will not be nice to you: it will show
> conflicts, and you have to resolve them.
>
> Or do you use "-s ours"?
No, nothing like that. I have had a situation where by a merge from
branchX to master has resulted in master's changes to fileA being
reverted based on what was in the contents of fileA in branchX -- this
is of course wrong though -- master hsa the most recent copy. My
solution therefore was to cherry pick the commit into branchX and
remerge into master. This is why I was forced to ask about whether or
not git-rebase was the correct way to go.
Although I suppose this leads me to the ancillory question of: At the
point I merged master into branchX did this cause any problems for any
future merges of branchX into master? I cannot recall if this
"revert scenario" I describe to master happened pre or past my merge
of master into branchX, but I suspect it was after I had merged master
into branchX.
-- Thomas Adam
^ permalink raw reply
* Re: Submodules
From: Junio C Hamano @ 2007-08-08 22:08 UTC (permalink / raw)
To: skimo; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <20070808200831.GS999MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> 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.
Heh, I do not have infinite time to spend on every little corner
features, and have been hoping that other people who have more
immediate need of submodule support to be the guinea pigs to
encounter real-life issues first and come up with solutions to
them, before I start using it.
So far, I think the plan has been working out alright ;-).
^ permalink raw reply
* [StGIT PATCH] Add an --smtp-server commandline option to "stg add"
From: Karl Hasselström @ 2007-08-08 22:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The configuration option stgit.smtpserver is useful if you always talk
to the same SMTP server. But I usually set up a temporary ssh tunnel,
so I'd rather have a commandline option.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
This patch is sent using the --smtp-server commandline option. Pure
magic!
stgit/commands/mail.py | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index cb8dc74..a7f7151 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -28,10 +28,11 @@ from stgit.config import config
help = 'send a patch or series of patches by e-mail'
usage = """%prog [options] [<patch1>] [<patch2>] [<patch3>..<patch4>]
-Send a patch or a range of patches by e-mail using the 'smtpserver'
-configuration option. The From address and the e-mail format are
-generated from the template file passed as argument to '--template'
-(defaulting to '.git/patchmail.tmpl' or
+Send a patch or a range of patches by e-mail using the SMTP server
+specified by the 'stgit.smtpserver' configuration option, or the
+'--smtp-server' command line option. The From address and the e-mail
+format are generated from the template file passed as argument to
+'--template' (defaulting to '.git/patchmail.tmpl' or
'~/.stgit/templates/patchmail.tmpl' or
'/usr/share/stgit/templates/patchmail.tmpl').
@@ -117,6 +118,8 @@ options = [make_option('-a', '--all',
help = 'sleep for SECONDS between e-mails sending'),
make_option('--refid',
help = 'use REFID as the reference id'),
+ make_option('--smtp-server', metavar = 'HOST[:PORT]',
+ help = 'SMTP server to use for sending mail'),
make_option('-u', '--smtp-user', metavar = 'USER',
help = 'username for SMTP authentication'),
make_option('-p', '--smtp-password', metavar = 'PASSWORD',
@@ -465,7 +468,7 @@ def func(parser, options, args):
"""Send the patches by e-mail using the patchmail.tmpl file as
a template
"""
- smtpserver = config.get('stgit.smtpserver')
+ smtpserver = options.smtp_server or config.get('stgit.smtpserver')
applied = crt_series.get_applied()
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox