* 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: 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
* [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: 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
* 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
* 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: 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
* 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: 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: [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
* [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
* [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] 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
* [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
* 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
* 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: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 18:25 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Denis Bueno, Git Mailing List
In-Reply-To: <20080711161158.GD10347@genesis.frugalware.org>
Hi,
On Fri, 11 Jul 2008, Miklos Vajna 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 ;-)
He did not ;-) "git reset" resets only the index, which is what I wanted.
Anyway, back to Denis' question: I could imagine (haven't tested,
thought), that "git revert -n <the-same-commit>" would undo the "git
cherry-pick -n".
Please test and report back,
Dscho
^ permalink raw reply
* Re: git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111924180.8950@racer>
On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Anyway, back to Denis' question: I could imagine (haven't tested,
> thought), that "git revert -n <the-same-commit>" would undo the "git
> cherry-pick -n".
So I need to be able to maintain the patch that is applied to the tree
before archiving, so instead of a commit ID, I'm now using a patch
file, and the sequence of actions is like so:
$ <assume index is clean>
$ git apply --cached patchfile || exit 1
$ git archive --format=tar --prefix=pfx/ $(git write-tree) \
| gzip > prj.tgz
$ git reset
This way I don't even need to reverse-apply the patch, because I never
touch the working copy. Of course, this can't be done in this way in
any other revision control system, because they don't have an index.
--
Denis
^ permalink raw reply
* Re: how to undo a git merge?
From: Jakub Narebski @ 2008-07-11 18:36 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807111108y3a8a7c3di19598a56dbbcdc15@mail.gmail.com>
ff (?) wrote:
>
> 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?
It is _number_ of parent.
-m parent-number, --mainline parent-number
Usually you cannot revert a merge because you do not know which side
of the merge should be considered the mainline. This option speci-
fies the parent number (starting from 1) of the mainline and allows
revert to reverse the change relative to the specified parent.
Merge commit has more than one parent. What git-revert does, it
creates commit which reverts the changes, as if applying "reversal"
diff, "git diff -R <revision>^<parent-number> <revision>".
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 18:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <A065AF71-5685-423A-9F87-5349ADC6C9C9@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> 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.
Which very much includes brushing up the patches in 4msysgit, which are
invariably of lower quality than git.git's, because we lack a brilliant
maintainer like Junio.
Come to think of it, we do not have a maintainer at all. Many people can
commit and push into 4msysgit, and I am debating with myself for a long
time already if that was a sensible thing to do. Just think of that C#
desaster.
> >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.
Junio expressed several times that he is uncomfortable that he cannot
easily test Windows support himself.
I strongly doubt that discussing things on git@vger that are not even
half-cooked would help that impression.
Also, there are a lot of people on git@vger who could not care _less_
about Windows.
And there are a few on the list who could not care less about those
Windows users who seem to be content to let others work for them, but
comment at every _possible_ occasion, on what should, and what should not
be done. Let's keep them on the msysGit list, for the benefit of the
saner half of git@vger.
> > > >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?
See above. There will be a rudimentary support for MinGW, yes, but that's
for hardcore people like Hannes.
For those who just want to use Git on Windows, there is msysGit. And
for them, we have the msysGit list.
Let's not confuse things, let's not upset git@vger with too many less
clueful users who should rather post to msysgit@googlegroups.com.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable
From: Johannes Schindelin @ 2008-07-11 18:42 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Dmitry Kakurin
In-Reply-To: <1215794896-31354-1-git-send-email-prohaska@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> 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--;
This is one of the things that are very specific to Windows and should not
affect other people.
Ciao,
Dscho
P.S.: this is one of the examples why I would like to discuss things that
are Windows-only on the msysGit list, until we have a consensus there. We
have a few Git experts there, you and Hannes in particular, which cover
that side, but also some Windows experts such as Peter and Marius, and we
should not need to have that discussion on a list where people are not
expected to care about Windows _at all_.
^ permalink raw reply
* Re: how to undo a git merge?
From: ff @ 2008-07-11 18:46 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080711181413.GI10347@genesis.frugalware.org>
> [ Did you reply off-list intentionally? ]
ooops... yes... I'm scared of the reply-all button. :)
> 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'.
Ok, so... sorry for not getting it completely, even after reading the info.
In your example, how and why you can determine that the number 1
represents the "foo" branch? Would "-m 2" represent the master branch?
In your example is there any other choice for the "-m" number to use?
-- ff
On Fri, Jul 11, 2008 at 2:14 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> [ 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'.
>
^ permalink raw reply
* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 18:46 UTC (permalink / raw)
To: Denis Bueno; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <6dbd4d000807111128l4721113dh3713bc7abd3d837e@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
> On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Anyway, back to Denis' question: I could imagine (haven't tested,
> > thought), that "git revert -n <the-same-commit>" would undo the "git
> > cherry-pick -n".
>
> So I need to be able to maintain the patch that is applied to the tree
> before archiving, so instead of a commit ID, I'm now using a patch
> file, and the sequence of actions is like so:
>
> $ <assume index is clean>
> $ git apply --cached patchfile || exit 1
> $ git archive --format=tar --prefix=pfx/ $(git write-tree) \
> | gzip > prj.tgz
> $ git reset
>
> This way I don't even need to reverse-apply the patch, because I never
> touch the working copy. Of course, this can't be done in this way in
> any other revision control system, because they don't have an index.
Well, they have. They just do not expose it.
BTW in your case, I would suggest this:
INDEX_FILE=.git/bla git read-tree HEAD &&
INDEX_FILE=.git/bla git apply --cached patchfile &&
INDEX_FILE=.git/bla git archive [...] &&
rm .git/bla
IOW: Just use a temporary index for your work.
Ciao,
Dscho
^ permalink raw reply
* Re: git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 18:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111944000.8950@racer>
On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> BTW in your case, I would suggest this:
>
> INDEX_FILE=.git/bla git read-tree HEAD &&
> INDEX_FILE=.git/bla git apply --cached patchfile &&
> INDEX_FILE=.git/bla git archive [...] &&
> rm .git/bla
>
> IOW: Just use a temporary index for your work.
What is the rationale? So I can relieve the assumption that the index is clean?
--
Denis
^ permalink raw reply
* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 18:53 UTC (permalink / raw)
To: Denis Bueno; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <6dbd4d000807111149s4fb661cak9fac152864260901@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
> On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > BTW in your case, I would suggest this:
> >
> > INDEX_FILE=.git/bla git read-tree HEAD &&
> > INDEX_FILE=.git/bla git apply --cached patchfile &&
> > INDEX_FILE=.git/bla git archive [...] &&
> > rm .git/bla
> >
> > IOW: Just use a temporary index for your work.
>
> What is the rationale? So I can relieve the assumption that the index
> is clean?
Not completely.
It will just leave the current index alone, ignoring the changes within
it. It will also avoid having to update the index several times.
IMO it is just the thing you should do here: you do not want to stage
anything for commit, so keep .git/index as-is, and use a temporary staging
area instead.
It also avoids the need to "undo" things that might not be easily undone:
if your patch contains stuff that was partly in the index, but
uncommitted, neither "git reset" nor "git revert -n" will do what you
want.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox