* [PATCH] block-sha1: Use mozilla-sha1 copyright and license information
From: Ulrik Sverdrup @ 2009-08-24 12:07 UTC (permalink / raw)
To: git
block-sha1 needs an independent copyright and license header, in the
case that the original mozilla SHA-1 implementation is removed from
the tree.
The Contributor(s) list in the header is not in the git style, but
it is copied as well, and augmented with git contributors to
block-sha1.
Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
---
block-sha1/sha1.{ch} simply say this:
/*
* Based on the Mozilla SHA1 (see mozilla-sha1/sha1.c),
* optimized to do word accesses rather than byte accesses,
* and to avoid unnecessary copies into the context array.
*/
This means that if mozilla-sha1 is removed, we need to copy the
license information back to block-sha1.
block-sha1/sha1.c | 38 +++++++++++++++++++++++++++++++++++++-
block-sha1/sha1.h | 37 ++++++++++++++++++++++++++++++++++---
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..34c7415 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -1,5 +1,41 @@
/*
- * Based on the Mozilla SHA1 (see mozilla-sha1/sha1.c),
+ * The contents of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * The Original Code is SHA 180-1 Reference Implementation (Compact version)
+ *
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research. Portions created by Paul Kocher are
+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All
+ * Rights Reserved.
+ *
+ * Contributor(s):
+ *
+ * Paul Kocher
+ * Linus Torvalds
+ * Nicolas Pitre
+ *
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
+ */
+/*
+ * Based on the Mozilla SHA1, this implementation is
* optimized to do word accesses rather than byte accesses,
* and to avoid unnecessary copies into the context array.
*/
diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h
index c1ae74d..dc72ccf 100644
--- a/block-sha1/sha1.h
+++ b/block-sha1/sha1.h
@@ -1,7 +1,38 @@
/*
- * Based on the Mozilla SHA1 (see mozilla-sha1/sha1.h),
- * optimized to do word accesses rather than byte accesses,
- * and to avoid unnecessary copies into the context array.
+ * The contents of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * The Original Code is SHA 180-1 Header File
+ *
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research. Portions created by Paul Kocher are
+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All
+ * Rights Reserved.
+ *
+ * Contributor(s):
+ *
+ * Paul Kocher
+ * Linus Torvalds
+ * Nicolas Pitre
+ *
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
*/
typedef struct {
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Ulrik Sverdrup @ 2009-08-24 11:42 UTC (permalink / raw)
To: nico; +Cc: git
block-sha1/sha1.{ch} simply say this:
/*
* Based on the Mozilla SHA1 (see mozilla-sha1/sha1.c),
* optimized to do word accesses rather than byte accesses,
* and to avoid unnecessary copies into the context array.
*/
This means that if mozilla-sha1 is removed, we need to copy the
license information back to block-sha1.
Ulrik
^ permalink raw reply
* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Johannes Schindelin @ 2009-08-24 11:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908240011010.6044@xanadu.home>
Hi,
On Mon, 24 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Johannes Schindelin wrote:
>
> > On Mon, 17 Aug 2009, Nicolas Pitre wrote:
> >
> > > They are both slower than the new BLK_SHA1 implementation, so it is
> > > pointless to keep them around.
> > >
> > > Signed-off-by: Nicolas Pitre <nico@cam.org> ---
> > >
> > > Someone else would need to make the call for the PPC version.
> >
> > If I don't forget, I can test tomorrow on 2 different 32-bit PPCs and
> > possibly one 64-bit PPC.
>
> Did you forget? ;-)
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Matthieu Moy @ 2009-08-24 11:07 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: David Aguilar, Nanako Shiraishi, git
In-Reply-To: <4A92703E.90007@microchip.com>
Sanjiv Gupta <sanjiv.gupta@microchip.com> writes:
> I was looking for post-mortem change-that-introduced-bug.
If so, then you don't need to test every commit. As David mentionned,
"git bisect" is your friend, and will do a binary search, finding the
culprit commit much more efficiently (run the testsuite log(n) times
instead of n times).
OTOH, if you want some kind of quality insurance (i.e. check that
every commit is OK, including the case where a commit introduces a
bug, and the next one fixes it), bisect is rather helpless.
--
Matthieu
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-24 10:49 UTC (permalink / raw)
To: David Aguilar; +Cc: Nanako Shiraishi, git
In-Reply-To: <20090824102242.GA70861@gmail.com>
David Aguilar wrote:
> On Mon, Aug 24, 2009 at 11:52:07AM +0530, Sanjiv Gupta wrote:
>
>> Excellent description. Thanks for that. I want to merge commits one by
>> one because I want to run a regression suite on each commit and
>> therefore know if any one is causing failures.
>>
>
> 'git bisect' is your friend.
>
> If your developers are disciplined and test each change as they
> commit it then you're going to have fewer problems.
>
> If they aren't, then make 'em send you patches. Then you can
> at least 'git am' each one and run the tests at each step,
> including the critical steps where you merge various topics
> together.
>
> I'm not sure what exactly you're trying to accomplish, though.
> I'm just making guesses without you telling us more.
>
> Are you trying to do post-mortem change-that-introduced-bug
> finding (git bisect), commit-time bug prevention
> (patch-based workflows, using git commit hooks to disallow
> commits that fail the tests, etc), or is it something
> completely different?
>
>
> HTH,
>
>
Thanks everyone for the overwhelming response.
I was looking for post-mortem change-that-introduced-bug.
It's also called "buildbot" in other terms, which sends you an email
with the details of the "culprit" commit as soon as it introduces a bug.
- Sanjiv
-
^ permalink raw reply
* Re: Pulling one commit at a time.
From: David Aguilar @ 2009-08-24 10:22 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Nanako Shiraishi, git
In-Reply-To: <4A92318F.6050105@microchip.com>
On Mon, Aug 24, 2009 at 11:52:07AM +0530, Sanjiv Gupta wrote:
> Excellent description. Thanks for that. I want to merge commits one by
> one because I want to run a regression suite on each commit and
> therefore know if any one is causing failures.
'git bisect' is your friend.
If your developers are disciplined and test each change as they
commit it then you're going to have fewer problems.
If they aren't, then make 'em send you patches. Then you can
at least 'git am' each one and run the tests at each step,
including the critical steps where you merge various topics
together.
I'm not sure what exactly you're trying to accomplish, though.
I'm just making guesses without you telling us more.
Are you trying to do post-mortem change-that-introduced-bug
finding (git bisect), commit-time bug prevention
(patch-based workflows, using git commit hooks to disallow
commits that fail the tests, etc), or is it something
completely different?
HTH,
--
David
^ permalink raw reply
* Re: [PATCH] Makefile: Add NEEDS_CRYPTO_WITH_SSL
From: Alex Riesen @ 2009-08-24 9:45 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Junio C Hamano
In-Reply-To: <1250354813-81349-1-git-send-email-brian@gernhardtsoftware.com>
On Sat, Aug 15, 2009 at 18:46, Brian
Gernhardt<brian@gernhardtsoftware.com> wrote:
>
> After adding BLK_SHA1 to my config.mak, git-imap-send started giving me link
> errors:
>
> Undefined symbols:
> "_ERR_get_error", referenced from:
> _ssl_socket_perror in imap-send.o
> "_ERR_error_string", referenced from:
> _ssl_socket_perror in imap-send.o
>
> Some investigation led me to the fact that BLK_SHA1 removes LIB_4_CRYPTO from
> EXTLIBS. That let me find the missing functions in libcrypto. At first I
> considered making NEEDS_SSL_WITH_CRYPTO add -lcrypto to the SSL build flags
> but decided to go this route in case there are platforms that need it one way
> around and not the other.
As imap-send is the only one which uses the symbols, why not just add
LIB_4_CRYPTO
to its linking command? Like in the broken GMail-patch below:
diff --git a/Makefile b/Makefile
index 02ff867..33971f3 100644
--- a/Makefile
+++ b/Makefile
@@ -1503,7 +1503,7 @@ git-%$X: %.o $(GITLIBS)
git-imap-send$X: imap-send.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
+ $(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
http.o http-walker.o http-push.o: http.h
^ permalink raw reply related
* Re: [PATCH v2 05/14] Change regerror() definition from K&R style to ANSI C (C89)
From: Erik Faye-Lund @ 2009-08-24 9:42 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: lznuaa, msysgit, git
In-Reply-To: <0123e22f50dfd5e1b483a02cf550e5373125f1d.1250860247.git.mstormo@gmail.com>
On Fri, Aug 21, 2009 at 10:10 PM, Marius Storm-Olsen<mstormo@gmail.com> wrote:
> size_t
> -regerror (errcode, preg, errbuf, errbuf_size)
> - int errcode;
> - const regex_t *preg;
> - char *errbuf;
> - size_t errbuf_size;
> +regerror(int errcode, const regex_t *preg,
> + char *errbuf, size_t errbuf_size)
> {
Since the real reason isn't the K&R style defintion, but that
"errcode" has been typedef'ed, perhaps it's better to either do
something like this:
#ifdef _MSC_VER
#define errcode dummy_def
#include <crtdefs.h>
#undef errcode
#endif
...before the first crt-inclusion, or simply to rename "errcode" to
something like "error"? The latter can be done with the preprocessor
after the first crt-inclusion.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Matthieu Moy @ 2009-08-24 8:41 UTC (permalink / raw)
To: skillzero; +Cc: Sanjiv Gupta, Kai Blin, Nanako Shiraishi, git
In-Reply-To: <2729632a0908240133t12eaafd5oe8d50af6d6eec566@mail.gmail.com>
skillzero@gmail.com writes:
> On Mon, Aug 24, 2009 at 12:55 AM, Sanjiv
> Gupta<sanjiv.gupta@microchip.com> wrote:
>
>> What I would like is to "test *every* commit" available in the public
>> master. There would be no local changes or commits that aren't pushed in the
>> private copy.
>> So I just want to clone one copy from the public master and then just keep
>> pulling commits from the public master one by one and run regressions on
>> each one.
>>
>> It's a damn simple thing in SVN world.
>> $ svn info will give you the current version you are at, assume it is
>> "cur_rev"
>> $ svn update -r `expr $cur_rev + 1`
>> $ build
>> $ test
>
> I'm not sure if this is the best way, but you can use git fetch to get
> the latest stuff from the server without merging it then you can merge
> from origin/master (i.e. the server) into your local master, one
> commit at a time, and verify at each step:
See my other reply, but I really don't think you want to _merge_ one
commit at a time. This would not mean "test each commit" but "test the
interaction between any two commits", which few people would care
about.
The example above in SVN doesn't merge each commit, it just walks
history (assuming the history is linear, the example wouldn't be as
simple if it had to walk /branches/* too). To continue the analogy,
merging commits one by one in Git would be more or less the equivalent
in SVN of:
$ svn status
# Hmm, OK, I have stuff to commit.
$ test
# Yes, it works. But do my changes work too on top of the previous
# commits?
$ while ...; do
svn update $(($cur_rev - 1))
build
test
done
# If so, then
$ svn update
$ svn commit
That is: test the interaction between your new change with any other
changes in the repository. 'never seen anyone interested by such
thing, but why not ;-).
--
Matthieu
^ permalink raw reply
* Re: Pulling one commit at a time.
From: skillzero @ 2009-08-24 8:33 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <4A92476A.4060205@microchip.com>
On Mon, Aug 24, 2009 at 12:55 AM, Sanjiv
Gupta<sanjiv.gupta@microchip.com> wrote:
> What I would like is to "test *every* commit" available in the public
> master. There would be no local changes or commits that aren't pushed in the
> private copy.
> So I just want to clone one copy from the public master and then just keep
> pulling commits from the public master one by one and run regressions on
> each one.
>
> It's a damn simple thing in SVN world.
> $ svn info will give you the current version you are at, assume it is
> "cur_rev"
> $ svn update -r `expr $cur_rev + 1`
> $ build
> $ test
I'm not sure if this is the best way, but you can use git fetch to get
the latest stuff from the server without merging it then you can merge
from origin/master (i.e. the server) into your local master, one
commit at a time, and verify at each step:
$ git merge `git log --format=%h master..origin/master | sed '$!d'`
$ build
$ test
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Matthieu Moy @ 2009-08-24 8:28 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <4A92476A.4060205@microchip.com>
Sanjiv Gupta <sanjiv.gupta@microchip.com> writes:
> What I would like is to "test *every* commit" available in the
> public master.
Then, you don't want to _merge_ each of them, you want to _fetch_ and
test each of them (Erik Faye-Lund's reply gives a solution for that).
Fetching is about getting existing commits from another repository,
while merging is about creating new commits.
--
Matthieu
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sean Estabrooks @ 2009-08-24 8:20 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <4A92476A.4060205@microchip.com>
On Mon, 24 Aug 2009 13:25:22 +0530
Sanjiv Gupta <sanjiv.gupta@microchip.com> wrote:
Hi Sanjiv,
> What I would like is to "test *every* commit" available in the public
> master. There would be no local changes or commits that aren't pushed in
> the private copy.
> So I just want to clone one copy from the public master and then just
> keep pulling commits from the public master one by one and run
> regressions on each one.
There's no reason to ask for the commits from the public master one by
one. You can download them all in one operation. After that it is
a local operation to checkout each new commit and build-test it. This
is more efficient than needing a network operation to get each commit
individually.
As an aside, you might not really need to test each and every commit.
It is likely enough to just test the most recent commit since it is
built on top of all the commits that came before it. Essentially
you'd be testing all the new commits at once and only need to test
more commits (git bisect) if you found a regression with that first
test.
> It's a damn simple thing in SVN world.
With Git you have a complete local copy of the history. Once you're
up to date with remote master you can checkout each new commit at
your leisure pretty damn simply ;o)
Cheers,
Sean
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Erik Faye-Lund @ 2009-08-24 8:22 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <40aa078e0908240120o36004f78m52aa34c8a338854c@mail.gmail.com>
> $ git merge FETCH_HEAD
Uhm, of course, you'd have to reattach HEAD to your branch before
merging. My bad ;)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Erik Faye-Lund @ 2009-08-24 8:20 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <4A92476A.4060205@microchip.com>
On Mon, Aug 24, 2009 at 9:55 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:
> It's a damn simple thing in SVN world.
> $ svn info will give you the current version you are at, assume it is
> "cur_rev"
> $ svn update -r `expr $cur_rev + 1`
> $ build
> $ test
I guess you could do it something like this. Unlike your example, this
processes all new commits, not just the next one.
$ git fetch origin master
$ for c in $(git rev-list HEAD..FETCH_HEAD); do
$ git checkout $c
$ build
$ test
$ done
$ git merge FETCH_HEAD
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Nanako Shiraishi @ 2009-08-24 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090824141623.6117@nanako3.lavabit.com>
Quoting myself...
> A scissors mark doesn't have to be at the beginning. The line has to
> contain the mark, and it has to consist of only the mark, '-' minus, the
> phrase "cut here", and whitespaces.
Junio, perhaps you want to squash some documentation, too.
-- 8< -- cut here -- 8< -- cut here -- 8< --
Subject: [PATCH] Documentation: describe the scissors mark support of "git am"
Describe what a scissors mark looks like, and explain in what situation
it is often used.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-am.txt | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..fecd5ac 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -128,10 +128,18 @@ the commit, after stripping common prefix "[PATCH <anything>]".
The "Subject: " line is supposed to concisely describe what the
commit is about in one line of text.
-"From: " and "Subject: " lines starting the body (the rest of the
-message after the blank line terminating the RFC2822 headers)
-override the respective commit author name and title values taken
-from the headers.
+A line that contains a scissors mark (either ">8" or "8<") and does not
+have anything other than scissors, dash (-), whitespaces or a phrase "cut
+here" is called a scissors line. If such a line appears in the body of the
+message before the patch, everything before it (including the scissors
+line itself) is ignored. This is useful if you want to begin your message
+in a discussion thread with comments and suggestions on the message you
+are responding to, and to conclude it with a patch submission, separating
+the discussion and the beginning of the proposed commit log message with a
+scissors line.
+
+"From: " and "Subject: " lines starting the body override the respective
+commit author name and title values taken from the headers.
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-24 7:55 UTC (permalink / raw)
To: Kai Blin; +Cc: Nanako Shiraishi, git
In-Reply-To: <200908240946.52813.kai@samba.org>
Kai Blin wrote:
> On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote:
>
>
>>> In general the public history isn't necessarily a single straight line
>>> like this picture and it doesn't make sense to merge one at a time for
>>> all the commits on the public branch, but if that is what you really want
>>> to do, you can do so.
>>>
>> Excellent description. Thanks for that. I want to merge commits one by
>> one because I want to run a regression suite on each commit and
>> therefore know if any one is causing failures.
>>
>
> What I do for a case like this is using rebase. I'm not sure if I get the
> explanation right enough to please all the git gurus on the list, but I'll
> try. What this basically does is to back out all the commits you did on your
> branch to the point you diverged from the branch you're rebasing on now.
>
> So assuming you had a structure like this:
>
> your 'master' HEAD
> |
> A---B---C
> /
> ---X---U---V---W---Y
> |
> public 'master' HEAD
>
> git would back out commits A-C, so your local branch HEAD would be at X. Then,
> if forwards your branch to the branch you're rebasing on, so your local
> branch HEAD is at Y now, like the public branch HEAD.
>
> After that, git applies all of your patches back to your local branch,
> producing a tree that looks like this:
>
> your 'master' HEAD
> |
> A---B---C
> /
> ---X---U---V---W---Y
> |
> public 'master' head
>
> Personally I prefer that solution as it keeps the history linear. Of course
> this means that all of your commits change sha1s, and you should not do this
> on public branches with tags. But if you're still developing, it's much
> easier to wrap your head around a history like this. It's also nice to
> present feature branches to other people, as all of your commits are in one
> block, without lots of annoying merge commits between them.
>
> rebase also handles more complicated cases of merging, but from the way I
> understood your issue, this should already help.
>
> Cheers,
> Kai
>
Thanks Kai.
What I would like is to "test *every* commit" available in the public
master. There would be no local changes or commits that aren't pushed in
the private copy.
So I just want to clone one copy from the public master and then just
keep pulling commits from the public master one by one and run
regressions on each one.
It's a damn simple thing in SVN world.
$ svn info will give you the current version you are at, assume it is
"cur_rev"
$ svn update -r `expr $cur_rev + 1`
$ build
$ test
Thanks,
- Sanjiv
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Kai Blin @ 2009-08-24 7:46 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Nanako Shiraishi, git
In-Reply-To: <4A92318F.6050105@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote:
> > In general the public history isn't necessarily a single straight line
> > like this picture and it doesn't make sense to merge one at a time for
> > all the commits on the public branch, but if that is what you really want
> > to do, you can do so.
>
> Excellent description. Thanks for that. I want to merge commits one by
> one because I want to run a regression suite on each commit and
> therefore know if any one is causing failures.
What I do for a case like this is using rebase. I'm not sure if I get the
explanation right enough to please all the git gurus on the list, but I'll
try. What this basically does is to back out all the commits you did on your
branch to the point you diverged from the branch you're rebasing on now.
So assuming you had a structure like this:
your 'master' HEAD
|
A---B---C
/
---X---U---V---W---Y
|
public 'master' HEAD
git would back out commits A-C, so your local branch HEAD would be at X. Then,
if forwards your branch to the branch you're rebasing on, so your local
branch HEAD is at Y now, like the public branch HEAD.
After that, git applies all of your patches back to your local branch,
producing a tree that looks like this:
your 'master' HEAD
|
A---B---C
/
---X---U---V---W---Y
|
public 'master' head
Personally I prefer that solution as it keeps the history linear. Of course
this means that all of your commits change sha1s, and you should not do this
on public branches with tags. But if you're still developing, it's much
easier to wrap your head around a history like this. It's also nice to
present feature branches to other people, as all of your commits are in one
block, without lots of annoying merge commits between them.
rebase also handles more complicated cases of merging, but from the way I
understood your issue, this should already help.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 7:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin, Don Zickus
In-Reply-To: <7v7hwtofys.fsf@alter.siamese.dyndns.org>
( cc'ing Don Zickus )
The 23/08/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> >> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
> >> the way?
> >
> > Has been added by 87ab799234639c .
>
> That much I know ;-), thanks anyway.
>
> The commit does not _explain_ what they are for, what they mean, and what
> these mysteriously named variables do.
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 7:24 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Nanako Shiraishi, Junio C Hamano, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <20090824071711.GE3526@vidovic>
( Paste error, sorry. )
The 24/08/09, Nicolas Sebrecht wrote:
> [ Please, please, please, wrap your lines. ]
>
> The 24/08/09, Nanako Shiraishi wrote:
>
> > Looking at the way other people use the mark in their messages, I think this explanation isn't correct.
>
> I'd say that should not document what people do but what the program
> does.
>
> > A scissors mark doesn't have to be at the beginning. The line has to contain the mark, and it has to consist of only the mark, '-' minus, the phrase "cut here", and whitespaces.
>
> ...and (">8" or "<8"), you're right. But isn't the following mark a bit
> too much permissive?
->8
Subject: [PATCH] squashme to 925bd84 (Teach mailinfo to ignore everything before -- >8 -- mark, 2009-08-23)
---
Documentation/git-am.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..5294d47 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -138,6 +138,12 @@ The commit message is formed by the title taken
from the
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
+If a line contains a mark in the body of the message, everything
+before (and the line itself) will be ignored. A mark has typically
+the form "-- >8 -- cut here -- >8 --". Strictly speacking, it must
+have one dash at least and a ">8" (or "<8"). Spaces and strings
+"cut here" are permited.
+
The patch is expected to be inline, directly following the
message. Any line that is of the form:
--
Nicolas Sebrecht
^ permalink raw reply related
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 7:17 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Nicolas Sebrecht, Junio C Hamano, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <20090824141623.6117@nanako3.lavabit.com>
[ Please, please, please, wrap your lines. ]
The 24/08/09, Nanako Shiraishi wrote:
> Looking at the way other people use the mark in their messages, I think this explanation isn't correct.
I'd say that should not document what people do but what the program
does.
> A scissors mark doesn't have to be at the beginning. The line has to contain the mark, and it has to consist of only the mark, '-' minus, the phrase "cut here", and whitespaces.
...and (">8" or "<8"), you're right. But isn't the following mark a bit
too much permissive?
->8
Subject: [PATCH] squashable to 925bd84 (Teach mailinfo to ignore everything before -- >8 -- mark, 2009-08-23)
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
This patch supersedes my previous round.
Documentation/git-am.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..1d10371 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -138,6 +138,10 @@ The commit message is formed by the title taken
from the
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
+If a line starts with a "-- >8 --" mark in the body of the message,
+everything before (and the line itself) will be ignored.
+Whitespaces and strings "cut here" are tolerated.
+
The patch is expected to be inline, directly following the
message. Any line that is of the form:
--
Nicolas Sebrecht
^ permalink raw reply related
* Re: [msysGit] Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Marius Storm-Olsen @ 2009-08-24 7:03 UTC (permalink / raw)
To: Thiago Farina
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git,
lznuaa
In-Reply-To: <a4c8a6d00908231229v56eceeddue1b927a4e4e49ee3@mail.gmail.com>
Thiago Farina said the following on 23.08.2009 21:29:
> Marius, how common-cmds.h will be generated? In the header file says
> that it's generated by generate-cmdlist.sh, so the VS user will need
> to generate this file first (before compiling)?
> When I tried to compile after pulling from the repository, I couldn't,
> so I copied it from the the msysgit.
The easiest is just do the following on the command line, provided
that you have the msysgit environment available (so GNU Make etc):
make common-cmds.h
That will ensure that the file is generated correctly. After that you
can build with msvc, based on the patch series.
--
.marius
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 6:58 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Junio C Hamano, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin
In-Reply-To: <20090824062141.GD3526@vidovic>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
>> the way?
>
> Has been added by 87ab799234639c .
That much I know ;-), thanks anyway.
The commit does not _explain_ what they are for, what they mean, and what
these mysteriously named variables do.
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-24 6:22 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090824060710.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Sanjiv Gupta <sanjiv.gupta@microchip.com>
>
>
>> I just wanted to know how can I pull one commit at a time from public
>> repository.
>> e.g.
>> when I first cloned from the public repo, it was at X. now it has
>> reached Y. I just want to pull x+1.
>>
>
> When your histories look like this:
>
> A your 'master'
> /
> ---X---U---V---W---Y public 'master' (your 'origin')
>
> instead of creating a single merge like this with "git pull":
>
> A---------------M your 'master' (fully merges 'origin')
> / /
> ---X---U---V---W---Y public 'master'
>
> you want to create a history like this?
>
> A---J your 'master' (lacks V, W and Y)
> / /
> ---X---U---V---W---Y public 'master'
>
> For that, you can fetch first.
>
> git fetch origin
>
> Then look at the history in gitk
>
> gitk master origin
>
> And find the commit you are interested in merging (U in the above picture). And merge it.
>
> git merge origin~3
>
> Replace "origin~3" in the example above with whatever commit you want to merge the entire history leading to it.
>
> You can repeat this final step as many times you want. For example, if you want create a history like this:
>
> A---J---K---L---M your 'master'
> / / / / /
> ---X---U---V---W---Y public 'master'
>
> you can do so by repeating the last step for V, W and Y in turn.
>
> In general the public history isn't necessarily a single straight line like this picture and it doesn't make sense to merge one at a time for all the commits on the public branch, but if that is what you really want to do, you can do so.
>
>
Excellent description. Thanks for that. I want to merge commits one by
one because I want to run a regression suite on each commit and
therefore know if any one is causing failures.
- Sanjiv
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 6:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin
In-Reply-To: <7vmy5pojsg.fsf@alter.siamese.dyndns.org>
The 23/08/09, Junio C Hamano wrote:
> Try this patch, perhaps? I forgot to reset the mysteriously named s_hdr
> buffer.
Nice. Please add
Tested-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
> the way?
Has been added by 87ab799234639c .
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-24 6:02 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Johannes.Schindelin
In-Reply-To: <alpine.DEB.2.00.0908232044060.29625@GWPortableVCS>
Thell Fowler <git@tbfowler.name> writes:
> It passed every test I threw at it, although it seemed to be a tad bit
> slower than the previous revision on my sample data so I ran the following
> command several times for both the previous and current version:
>
> time for i in {1..10}; do ./t4015-diff-whitespace.sh>/dev/null &&
> ./t4015-diff-trailing-whitespace.sh >/dev/null; done
>
> And these results are fairly average on what I saw:
>
> Previous version:
> real 2m32.669s
> user 0m44.051s
> sys 1m34.702s
>
>
> Current version:
> real 2m56.818s
> user 0m47.671s
> sys 1m46.723s
Do you mean by "previous version" the one that was broken, or the one I
sent as a "how about" patch?
Here are the numbers I am getting:
$ /usr/bin/time sh -c 'for i in 1 2 3 4 5 6 7 8 9 0; do ./t4015-diff-whitespace.sh; done' >/dev/null
----------------
1.99user 3.65system 0:05.10elapsed 110%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288675minor)pagefaults 0swaps
1.86user 3.66system 0:05.04elapsed 109%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288618minor)pagefaults 0swaps
1.76user 3.87system 0:05.02elapsed 112%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288973minor)pagefaults 0swaps
----------------
1.81user 3.86system 0:05.08elapsed 111%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288836minor)pagefaults 0swaps
1.76user 3.87system 0:04.95elapsed 113%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288880minor)pagefaults 0swaps
1.81user 3.88system 0:05.04elapsed 112%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288530minor)pagefaults 0swaps
----------------
One set is with patch and one set is the patch reverted. I cannot quite
remember which one is which ;-) but the difference is within the noise for me.
I have to revisit this sometime after getting a long rest.
^ 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