* Re: how to undo a git merge?
From: Miklos Vajna @ 2008-07-11 18:14 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807111107o40c5cbb5xc06c3c56b16b7499@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
[ Did you reply off-list intentionally? ]
On Fri, Jul 11, 2008 at 02:07:44PM -0400, ff <ff@member.org> wrote:
> thank you.
>
> I did see the -m option in the revert man page. It talks about
> "parent" and I did
> not understand what that is. Is parent the commit id of the merge commit?
>
> Thanks again!
http://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_parent
A merge commit has two parents, but obviously only one of the was the
HEAD commit before the merge. So when you revert a merge, you need to
specify which which parent's tree should be the tree of the new HEAD.
For example, if you were on branch 'master' and you merged 'foo' to
master using 'git merge foo', and you want to revert that merge then you
need '-m 1'.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to undo a git merge?
From: Jakub Narebski @ 2008-07-11 17:13 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807110916x689e316fr6bae01f28e2e1acb@mail.gmail.com>
ff <ff@member.org> writes:
> I have two git branches that stem from the same exact master branch.
> Many commits happened independently on these two branches overtime.
> Then, I inadvertently did a merge from one branch into another. The branch
> where I merged into now has mixed commits, and also a commit for the merge
> itself. I then had more commits added to the branch that I merged into.
>
> Now I would like to revert the merge... what is the best way of doing that?
> I would like very much to use something like git-revert <merge_commit_id>
> But that does not seem to work.
If you have published history, then the only sane option is
"git revert -m". If you haven't published history, you can
try "git rebase --interactive".
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [StGIT] Failure to install on RHELWS4
From: Petr Baudis @ 2008-07-11 17:03 UTC (permalink / raw)
To: git
Hi,
I wanted to install latest HEAD of StGIT on a rather ancient-feeling
RHEL4, however, when doing python setup.py install, I'm getting
File "setup.py", line 31
pyver = '.'.join(str(n) for n in sys.version_info)
^
SyntaxError: invalid syntax
I don't really know python and the ^ is rather curiously-positioned, so
I don't have much clue on what is going on. Python version is 2.3.4 -
maybe that's too old, but I didn't find any word on the minimal Python
version nowhere in the documentation.
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* [PATCH] We need to check for msys as well as Windows in add--interactive.
From: Steffen Prohaska @ 2008-07-11 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Pape, Steffen Prohaska
From: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-add--interactive.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Nobody has commented on this patch, nor has it been applied.
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..78a64e6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -42,7 +42,7 @@ sub colored {
my $patch_mode;
sub run_cmd_pipe {
- if ($^O eq 'MSWin32') {
+ if ($^O eq 'MSWin32' || $^O eq 'msys') {
my @invalid = grep {m/[":*]/} @_;
die "$^O does not support: @invalid\n" if @invalid;
my @args = map { m/ /o ? "\"$_\"": $_ } @_;
--
1.5.6.1.282.gd8a0d
^ permalink raw reply related
* [PATCH] Convert CR/LF to LF in tag signatures
From: Steffen Prohaska @ 2008-07-11 16:55 UTC (permalink / raw)
To: git, Johannes Sixt
Cc: Junio C Hamano, Johannes Schindelin, Johannes Schindelin,
Steffen Prohaska
In-Reply-To: <200807022046.28141.johannes.sixt@telecom.at>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, gpg outputs CR/LF signatures. But since the tag messages
are already stripped of the CR by stripspace(), it is arguably nicer
to do the same for the tag signature. Actually, this patch does not
look for CR/LF, but strips all CRs from the signature. It does so not
only on Windows but on all platforms to keep the code simpler.
[ spr: ported code to use strbuf ]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
builtin-tag.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 3c97c69..a70922b 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -202,6 +202,7 @@ static int do_sign(struct strbuf *buffer)
const char *args[4];
char *bracket;
int len;
+ int i, j;
if (!*signingkey) {
if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
@@ -241,6 +242,15 @@ static int do_sign(struct strbuf *buffer)
if (finish_command(&gpg) || !len || len < 0)
return error("gpg failed to sign the tag");
+ /* Strip CR from the line endings, in case we are on Windows. */
+ for (i = j = 0; i < buffer->len; i++)
+ if (buffer->buf[i] != '\r') {
+ if (i != j)
+ buffer->buf[j] = buffer->buf[i];
+ j++;
+ }
+ strbuf_setlen(buffer, j);
+
return 0;
}
--
1.5.6.1.282.gd8a0d
^ permalink raw reply related
* [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable
From: Steffen Prohaska @ 2008-07-11 16:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dmitry Kakurin, Steffen Prohaska
In-Reply-To: <7vabh0d4t9.fsf@gitster.siamese.dyndns.org>
From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
convert.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/convert.c b/convert.c
index 352b69d..78efed8 100644
--- a/convert.c
+++ b/convert.c
@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
else
stats->printable++;
}
+
+ /* If file ends with EOF then don't count this EOF as non-printable. */
+ if (size >= 1 && buf[size-1] == '\032')
+ stats->nonprintable--;
}
/*
--
1.5.6.1.282.gd8a0d
^ permalink raw reply related
* Re: [PATCH 0/3] Git::Repo API and gitweb caching
From: Abhijit Menon-Sen @ 2008-07-11 16:27 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <4877691E.1010000@gmail.com>
At 2008-07-11 16:07:26 +0200, lewiemann@gmail.com wrote:
>
> > 'If-Not-Modified-Since', 'If-Match' (by caches)
>
> Wait, are you sure caches would use those headers (I believe only the
> latter actually exists BTW), or did you fall prey to a thinko? ;)
If-Not-Modified-Since should really be If-Unmodified-Since.
But where's the thinko? To send If-Modified-Since or similar with a
request, you would need to have a cached copy of the resource and use
its Last-Modified, for example. Sure, you could do it without one, but
what would be the point?
-- ams
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-11 16:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111652170.8950@racer>
On Jul 11, 2008, at 5:57 PM, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
>>
>>> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>>>
>>>> I decided to stop queuing changes in 4msysgit. Instead I'd like to
>>>> bring the diff between Junio's and 4msysgit's master to zero. This
>>>> seems to be achievable after Junio merged Hannes' MinGW changes.
>>>>
>>>> I think all Windows-related changes to the git code base could be
>>>> discussed directly on the main git list and the msysgit list
>>>> would be
>>>> reserved for the MinGW/MSYS runtime environment and the installer.
>>>
>>> I disagree. Judging from the mails I read on the git list, Junio
>>> gets
>>> really swamped by patches these days (what with our very
>>> productive GSoC
>>> students).
>>
>> Sending the patches to the git list does not necessarily mean that
>> they are directly addressed to Junio. We discuss JGIT, EGIT, gitk,
>> and git gui patches on the list too. AFAIK, none of them are applied
>> by Junio directly but by the respective maintainers. We could handle
>> Windows-related patches similarly.
>
> Then what is the msysGit list about?
I think the msysGit list could be useful for:
- Everything that is in the msysgit repo, i.e. the MinGW/MSYS
runtime environment and the installers.
- User questions, including the issue tracker.
> No, I really disagree. Windows support is too large a thing, and
> partly a
> too disgusting one to bother the git list.
My understanding is that the mainline of git starts supporting the MinGW
port with version 1.6.0. The MinGW port is merged to Junio's master, so
the remaining differences between Junio's master and 4msysgit's master
should be removed and afterwards new changes should be discussed,
improved,
and applied to Junio's master anyway. This would also allow to directly
test Junio's next on Windows.
>>> I really think that we should discuss the patches on the msysGit
>>> list
>>> first, whip them into shape, and then send them off.
>>>
>>> Just think of those patches that were sent off, only to realize that
>>> they were no longer needed. That should not have happened.
>>
>> I intentionally sent the patches to show and discuss the differences
>> between the state of the MinGW port in Junio's master and in
>> 4msysgit.
>> Some of the patches could be reverted in 4msysgit. But, at least one
>> patch was unrelated to MinGW and is now in master. Some other
>> patches
>> need more work and are currently improved. I think this was not a
>> waste
>> of time.
>
> IMO we could have discussed first what is the current state on the
> msysGit
> list, and I would have commented there already on the patches that I
> think
> would no longer be needed.
>
> Then the patch would have been sent off, and be in master, too.
>
> The difference: it would have been more efficient. Those people who
> can
> test if something is still needed on Windows are on the msysGit list.
>
> We do not really need to clutter git@vger more than necessary.
But git 1.6 will contain the MinGW port. Shouldn't related patches
then be discussed on git@vger?
Steffen
^ permalink raw reply
* Re: how to undo a git merge?
From: Miklos Vajna @ 2008-07-11 16:19 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807110916x689e316fr6bae01f28e2e1acb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
On Fri, Jul 11, 2008 at 12:16:15PM -0400, ff <ff@member.org> wrote:
> Now I would like to revert the merge... what is the best way of doing that?
> I would like very much to use something like git-revert <merge_commit_id>
> But that does not seem to work.
git revert has a '-m' option to revert merges. See the manpage.
> Any help/pointers of an example illustrating solution to this case
> would be greatly
> appreciated!
Actually if you just did that merge by accident, then probably you want
'git reset --hard HEAD^', not git revert, I think.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 16:18 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20080711161158.GD10347@genesis.frugalware.org>
On Fri, Jul 11, 2008 at 12:11, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Jul 11, 2008 at 12:09:02PM -0400, Denis Bueno <dbueno@gmail.com> wrote:
>> On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > $ git cherry-pick -n <bla>
>> > $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
>> > $ git reset
>
> I guess he wanted to write 'git reset --hard' here ;-)
But that will undo local modifications to any uncommitted files, not
just those affected by the cherry-pick. I don't want to do that.
>> Thank you! This is much better. The only thing that could improve it
>> is by some way to "un-cherry-pick" the applied change (so that after
>> "git reset" there are no local modifications to the file(s) changed by
>> cherry-picking <bla>).
>>
>> Is there an easy way to invert a patch to undo the change the original
>> patch introduced?
>
> git show <commit> | git apply -R?
Brilliant! Thanks. I didn't know about apply (or show for that matter ....).
--
Denis
^ permalink raw reply
* how to undo a git merge?
From: ff @ 2008-07-11 16:16 UTC (permalink / raw)
To: git
Hello,
I'm a git lover with a question.
I have two git branches that stem from the same exact master branch.
Many commits happened independently on these two branches overtime.
Then, I inadvertently did a merge from one branch into another. The branch
where I merged into now has mixed commits, and also a commit for the merge
itself. I then had more commits added to the branch that I merged into.
Now I would like to revert the merge... what is the best way of doing that?
I would like very much to use something like git-revert <merge_commit_id>
But that does not seem to work.
Any help/pointers of an example illustrating solution to this case
would be greatly
appreciated!
Regards,
-- ff@member.org
^ permalink raw reply
* Re: git cherry-pick before archive
From: Miklos Vajna @ 2008-07-11 16:11 UTC (permalink / raw)
To: Denis Bueno; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <6dbd4d000807110909n1ced22eeraef45af441c20cca@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
On Fri, Jul 11, 2008 at 12:09:02PM -0400, Denis Bueno <dbueno@gmail.com> wrote:
> On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > $ git cherry-pick -n <bla>
> > $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> > $ git reset
I guess he wanted to write 'git reset --hard' here ;-)
>
> Thank you! This is much better. The only thing that could improve it
> is by some way to "un-cherry-pick" the applied change (so that after
> "git reset" there are no local modifications to the file(s) changed by
> cherry-picking <bla>).
>
> Is there an easy way to invert a patch to undo the change the original
> patch introduced?
git show <commit> | git apply -R?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 16:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111649290.8950@racer>
On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> $ git cherry-pick -n <bla>
> $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> $ git reset
Thank you! This is much better. The only thing that could improve it
is by some way to "un-cherry-pick" the applied change (so that after
"git reset" there are no local modifications to the file(s) changed by
cherry-picking <bla>).
Is there an easy way to invert a patch to undo the change the original
patch introduced?
--
Denis
^ permalink raw reply
* [PATCH] git-bisect: use dash-less form on git bisect log
From: Miklos Vajna @ 2008-07-11 16:01 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <200807110839.14764.chriscool@tuxfamily.org>
Given that users are supposed to type 'git bisect' now, make the output
of 'git bisect log' consistent with this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Jul 11, 2008 at 08:39:14AM +0200, Christian Couder <chriscool@tuxfamily.org> wrote:
> Wouldn't it be better if bisect_replay could read old logs?
>
> Maybe with something like:
>
> + while read git bisect command rev
> do
> - test "$bisect" = "git-bisect" || continue
> + test "$git $bisect" = "git bisect" -o "$git" =
> "git-bisect" || continue
> + if test "$git" = "git-bisect"; then
> + rev="$command"
> + command="$bisect"
> + fi
You are right, here is an updated patch.
git-bisect.sh | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 991b2ef..3cac20d 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -149,7 +149,7 @@ bisect_start() {
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
sq "$@" >"$GIT_DIR/BISECT_NAMES" &&
eval "$eval" &&
- echo "git-bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
+ echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
#
# Check if we can proceed to the next bisect state.
#
@@ -169,7 +169,7 @@ bisect_write() {
esac
git update-ref "refs/bisect/$tag" "$rev" || exit
echo "# $state: $(git show-branch $rev)" >>"$GIT_DIR/BISECT_LOG"
- test -n "$nolog" || echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
+ test -n "$nolog" || echo "git bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
bisect_state() {
@@ -426,9 +426,13 @@ bisect_clean_state() {
bisect_replay () {
test -r "$1" || die "cannot read $1 for replaying"
bisect_reset
- while read bisect command rev
+ while read git bisect command rev
do
- test "$bisect" = "git-bisect" || continue
+ test "$git $bisect" = "git bisect" -o "$git" = "git-bisect" || continue
+ if test "$git" = "git-bisect"; then
+ rev="$command"
+ command="$bisect"
+ fi
case "$command" in
start)
cmd="bisect_start $rev"
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 15:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <65365AC4-D7C9-462B-8239-F3B35F7ECBEF@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
>
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >I decided to stop queuing changes in 4msysgit. Instead I'd like to
> > >bring the diff between Junio's and 4msysgit's master to zero. This
> > >seems to be achievable after Junio merged Hannes' MinGW changes.
> > >
> > >I think all Windows-related changes to the git code base could be
> > >discussed directly on the main git list and the msysgit list would be
> > >reserved for the MinGW/MSYS runtime environment and the installer.
> >
> >I disagree. Judging from the mails I read on the git list, Junio gets
> >really swamped by patches these days (what with our very productive GSoC
> >students).
>
> Sending the patches to the git list does not necessarily mean that
> they are directly addressed to Junio. We discuss JGIT, EGIT, gitk,
> and git gui patches on the list too. AFAIK, none of them are applied
> by Junio directly but by the respective maintainers. We could handle
> Windows-related patches similarly.
Then what is the msysGit list about?
No, I really disagree. Windows support is too large a thing, and partly a
too disgusting one to bother the git list.
> >I really think that we should discuss the patches on the msysGit list
> >first, whip them into shape, and then send them off.
> >
> >Just think of those patches that were sent off, only to realize that
> >they were no longer needed. That should not have happened.
>
> I intentionally sent the patches to show and discuss the differences
> between the state of the MinGW port in Junio's master and in 4msysgit.
> Some of the patches could be reverted in 4msysgit. But, at least one
> patch was unrelated to MinGW and is now in master. Some other patches
> need more work and are currently improved. I think this was not a waste
> of time.
IMO we could have discussed first what is the current state on the msysGit
list, and I would have commented there already on the patches that I think
would no longer be needed.
Then the patch would have been sent off, and be in master, too.
The difference: it would have been more efficient. Those people who can
test if something is still needed on Windows are on the msysGit list.
We do not really need to clutter git@vger more than necessary.
Ciao,
Dscho
^ permalink raw reply
* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 15:51 UTC (permalink / raw)
To: Denis Bueno; +Cc: Git Mailing List
In-Reply-To: <6dbd4d000807110846m2921ddb9r88eb3986762b8f81@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
> I'm trying to use git archive to create a kind of "release" tarball of
> my source. I've got a patch (a commit) that I'd like to apply to the
> tree before I call git archive on HEAD. Currently my command is:
>
> git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>
> If I were to actually modify my tree & history, I'd change the command to:
>
> git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
> git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
> git reset --hard HEAD^
>
> But I'd rather not modify my history, if it's possible. (This will
> create a bunch of dangling commit objects over time, no?)
$ git cherry-pick -n <bla>
$ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
$ git reset
Hth,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-11 15:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111349470.3640@eeepc-johanness>
On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> I decided to stop queuing changes in 4msysgit. Instead I'd like to
>> bring the diff between Junio's and 4msysgit's master to zero. This
>> seems to be achievable after Junio merged Hannes' MinGW changes.
>>
>> I think all Windows-related changes to the git code base could be
>> discussed directly on the main git list and the msysgit list would be
>> reserved for the MinGW/MSYS runtime environment and the installer.
>
> I disagree. Judging from the mails I read on the git list, Junio gets
> really swamped by patches these days (what with our very productive
> GSoC
> students).
Sending the patches to the git list does not necessarily mean that
they are directly addressed to Junio. We discuss JGIT, EGIT, gitk,
and git gui patches on the list too. AFAIK, none of them are applied
by Junio directly but by the respective maintainers. We could handle
Windows-related patches similarly.
> I really think that we should discuss the patches on the msysGit list
> first, whip them into shape, and then send them off.
>
> Just think of those patches that were sent off, only to realize that
> they
> were no longer needed. That should not have happened.
I intentionally sent the patches to show and discuss the differences
between the state of the MinGW port in Junio's master and in 4msysgit.
Some of the patches could be reverted in 4msysgit. But, at least one
patch was unrelated to MinGW and is now in master. Some other patches
need more work and are currently improved. I think this was not a waste
of time.
Steffen
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-11 15:48 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807110841r329dfb95g786a576bd981dd1b@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Geoffrey Irving wrote:
> On Fri, Jul 11, 2008 at 8:36 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Why so complicated? I mean, you can count in that "infinite" loop
> > yourself, no?
>
> Yeah, I was just trying to avoid the extra termination condition,
> because I don't think it adds any real safety.
Sorry. You absolutely lost me. While doing the loop over the entries,
trying to find an entry, adding a counter, and exiting when the counter
reaches the total number of slots does not add any real safety?
Puzzled,
Dscho
^ permalink raw reply
* git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 15:46 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'm trying to use git archive to create a kind of "release" tarball of
my source. I've got a patch (a commit) that I'd like to apply to the
tree before I call git archive on HEAD. Currently my command is:
git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
If I were to actually modify my tree & history, I'd change the command to:
git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
git reset --hard HEAD^
But I'd rather not modify my history, if it's possible. (This will
create a bunch of dangling commit objects over time, no?)
--
Denis
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-11 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0807111635400.8950@racer>
On Fri, Jul 11, 2008 at 8:36 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 11 Jul 2008, Geoffrey Irving wrote:
>
>> On Thu, Jul 10, 2008 at 11:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > "Geoffrey Irving" <irving@naml.us> writes:
>> >
>> >>>> Oops: avoiding the infinite loop only requires reading expected O(1)
>> >>>> entries on load, so I can fix that if you like. It would only be all of
>> >>>> them if it actually did detect the infinite loop.
>> >>>
>> >>> I have to admit that you lost me there. AFAIR the patch-id cache is a
>> >>> simple commit->patch_id store, right? Then there should be no way to get
>> >>> an infinite loop.
>> >>
>> >> If every entry is nonnull, find_helper loops forever.
>> >
>> > Isn't it sufficient to make this part check the condition as well?
>> >
>> > + if (cache->count >= cache->size)
>> > + {
>> > + warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
>> > + filename, cache->count, cache->size);
>> > + goto empty;
>> > + }
>> >
>> > At runtime you keep the invariants that hashtable always has at most 3/4
>> > full and whoever wrote the file you are reading must have honored that as
>> > well, or there is something fishy going on.
>>
>> Good point. There's no reason not to check the 3/4 condition. It isn't
>> sufficient to avoid the infinite loop, though, since we don't verify
>> that count is accurate.
>
> Why so complicated? I mean, you can count in that "infinite" loop
> yourself, no?
Yeah, I was just trying to avoid the extra termination condition,
because I don't think it adds any real safety.
Geoffrey
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-11 15:36 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807110758y6c4ea7bepd726daf4fe5f074c@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Geoffrey Irving wrote:
> On Thu, Jul 10, 2008 at 11:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > "Geoffrey Irving" <irving@naml.us> writes:
> >
> >>>> Oops: avoiding the infinite loop only requires reading expected O(1)
> >>>> entries on load, so I can fix that if you like. It would only be all of
> >>>> them if it actually did detect the infinite loop.
> >>>
> >>> I have to admit that you lost me there. AFAIR the patch-id cache is a
> >>> simple commit->patch_id store, right? Then there should be no way to get
> >>> an infinite loop.
> >>
> >> If every entry is nonnull, find_helper loops forever.
> >
> > Isn't it sufficient to make this part check the condition as well?
> >
> > + if (cache->count >= cache->size)
> > + {
> > + warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
> > + filename, cache->count, cache->size);
> > + goto empty;
> > + }
> >
> > At runtime you keep the invariants that hashtable always has at most 3/4
> > full and whoever wrote the file you are reading must have honored that as
> > well, or there is something fishy going on.
>
> Good point. There's no reason not to check the 3/4 condition. It isn't
> sufficient to avoid the infinite loop, though, since we don't verify
> that count is accurate.
Why so complicated? I mean, you can count in that "infinite" loop
yourself, no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix backwards-incompatible handling of core.sharedRepository
From: Petr Baudis @ 2008-07-11 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6a1kmpq.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 10, 2008 at 10:34:57PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> >> The 06cbe8550324e0fd2290839bf3b9a92aa53b70ab core.sharedRepository
> >> handling extension broke backwards compatibility; before, shared=1 meant
> >> that Git merely ensured the repository is group-writable, not that it's
> >> _only_ group-writable, which is the current behaviour.
> >
> > Donn't our existing tests catch this, and if the answer is no because we
> > don't have any, could you add some?
(Will do. Wanted to do it but forgot. :-)
> >> diff --git a/path.c b/path.c
> >> index 5983255..75c5915 100644
> >> --- a/path.c
> >> +++ b/path.c
> >> @@ -269,7 +269,7 @@ int adjust_shared_perm(const char *path)
> >> mode = st.st_mode;
> >>
> >> if (shared_repository) {
> >> - int tweak = shared_repository;
> >> + int tweak = (mode & 0777) | shared_repository;
> >> if (!(mode & S_IWUSR))
> >> tweak &= ~0222;
> >> mode = (mode & ~0777) | tweak;
> >
> > I think this change is good. shared_repository has always been about
> > widening the access and not about limiting.
>
> Having said that, you really should protect this behaviour from regression
> with a test case. I do not see practical difference for sane umask
> values.
>
> What umask are you using, and which file in the repository gets affected?
> In the old code I see we do have checks for S_IXUSR and tweaks on S_IXGRP
> and S_IXOTH, but this should make a difference only if your umask blocks
> executable bit and the file in question is executable. Was it an
> executable hook copied from template?
My umask is 002, and the difference is visible at all the files in the
repository (in existing repositories, update will cause new object files
have the missing permission, making for the most confusing behaviour).
With sane Git versions, the permissions when shared=1 are rwxrwxr-x,
with recent Git however, it is rwxrwx--- (modulo the exec bits).
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-11 14:58 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Schindelin, git
In-Reply-To: <37fcd2780807110744k3b2a332csdf788dabd172622c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
At Friday 11 July 2008 16:44:23 Dmitry Potapov wrote :
> On Fri, Jul 11, 2008 at 5:39 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
> >
> > Ok, following the thread I understand why this feature isn't wanted by all. But
> > for the given example (where I only pulled from another git tree) this could
> > work, isn't it : ?
> >
> > tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'
>
> No, it does not. Running your script, I have
>
> ...
> 56 commit 803a9067e19714ea7b7da760fe92f0d53bfa6994
> ...
>
> Now, let's see what git-describe thinks about it
> $ git describe 803a9067e19714ea7b7da760fe92f0d53bfa6994
> v2.6.26-rc9-38-g803a906
>
> Your script is obviously incorrect. It is written in the assumption that
> history is linear, but it is not. Even if you pull only from one repo,
> this repo still contains *many* branches. Along any branch, you may have
> the same number.
>
> Dmitry
>
Yes,
$> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
I used eventually to get the commit id for the (broken) UML kernel 2.6.26-rc9-56
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-11 14:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git@vger.kernel.org
In-Reply-To: <7v3amglxmb.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 10, 2008 at 11:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Geoffrey Irving" <irving@naml.us> writes:
>
>>>> Oops: avoiding the infinite loop only requires reading expected O(1)
>>>> entries on load, so I can fix that if you like. It would only be all of
>>>> them if it actually did detect the infinite loop.
>>>
>>> I have to admit that you lost me there. AFAIR the patch-id cache is a
>>> simple commit->patch_id store, right? Then there should be no way to get
>>> an infinite loop.
>>
>> If every entry is nonnull, find_helper loops forever.
>
> Isn't it sufficient to make this part check the condition as well?
>
> + if (cache->count >= cache->size)
> + {
> + warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
> + filename, cache->count, cache->size);
> + goto empty;
> + }
>
> At runtime you keep the invariants that hashtable always has at most 3/4
> full and whoever wrote the file you are reading must have honored that as
> well, or there is something fishy going on.
Good point. There's no reason not to check the 3/4 condition. It
isn't sufficient to avoid the infinite loop, though, since we don't
verify that count is accurate.
Another route would to eliminate the count field entirely, and replace
the count >= size/4*3 check with a statistical one based on the
entries seen so far. The main advantage of that would be to make
incremental writes simpler by avoiding the need to update the header.
The disadvantage is that there would be a small chance that the map
would grow in size despite being almost empty. Thoughts on whether we
should do that?
>>> Besides, this is a purely local cache, no? Never to be transmitted... So
>>> not much chance of a malicious attack, except if you allow write access to
>>> your local repository, in which case you are endangered no matter what.
>>
>> Yep, that's why it's only a hole in quotes, and why I didn't fix it.
>
> You might want to protect yourself against file corruption, though.
> Checksumming the whole file and checking it at opening defeats the point
> of mmap'ed access, but at least the header may want to be checksummed?
Okay. I imagine I should use sha1 as the sum?
Geoffrey
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-11 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807111533310.8950@racer>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
At Friday 11 July 2008 16:36:07 Johannes Schindelin wrote :
> The question is not so much if it would work, but what people would do
> with this. They would probably include something in a mail to you like
> "v2.6.26-rc9-111 stopped working!", you would test "v2.6.26-rc9-111" and
> go back "but it still works!".
>
> Because you are talking about two different things.
>
> So, in what workflow would v2.6.26-rc9-111 actually be helpful? For
> yourself working in your own lil' branch? I do not think so. HEAD~23 is
> much more helpful in that case, since locally, you do not work so much
> relative to a given tag, but relative to your current HEAD.
>
> Hth,
> Dscho
Ah yes, this clarified it for me.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 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