* Problem compiling: that perl thing again
From: Luben Tuikov @ 2006-12-08 20:36 UTC (permalink / raw)
To: git
Over the last 2 months each time I pull, check out next and compile,
I'm seeing _some_ kind of problem with compiling the perl section
of git. Sometimes git-reset --hard, or a fresh checkout, or git-clean
resolve the situation. But not this time.
Here is what I see now:
$ make
...
make -C perl PERL_PATH='/usr/bin/perl' prefix='/home/luben' all
make[1]: Entering directory `/home/luben/projects/git-next/perl'
Makefile out-of-date with respect to Makefile.PL
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/Config.pm
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE/config.h
Cleaning current config before rebuilding Makefile...
mv: cannot stat `perl.mak': No such file or directory
make[1]: *** [perl.mak] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/luben/projects/git-next/perl'
make: *** [all] Error 2
$ git-rev-list --max-count=1 HEAD
e1e8377415c8754c3773c09b78baaffa89d6fa9e
So, where is "perl.mak"?
Luben
^ permalink raw reply
* Re: [PATCH 1/5] rerere: avoid misrecording on a skipped or aborted rebase/am
From: Junio C Hamano @ 2006-12-08 20:43 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11655749724034-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> +if (@ARGV && $ARGV[0] eq 'clear') {
> + for my $path (keys %merge_rr) {
> + my $name = $merge_rr{$path};
> + if (-d "$rr_dir/$name") {
> + rmtree(["$rr_dir/$name"]);
> + }
> + }
> + unlink $merge_rr;
> + exit 0;
> +}
Come to think of it, I am not sure about this one. Don't you
need to make sure that there is no existing resolution before
removing it? In other words, shouldn't the removal be like this?
if (-d "$rr_dir/$name" && ! -f "$rr_dir/$name/postimage") {
rmtree(["$rr_dir/$name"]);
}
^ permalink raw reply
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Junio C Hamano @ 2006-12-08 20:45 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061208193718.GA11906@soma>
Eric Wong <normalperson@yhbt.net> writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>>
>> git-sh-setup isn't a 'normal' binary, in that it should be called by
>> bash only and not run in a subshell. Therefore, it should not be installed
>> in a executable directory, but rather in $prefix/share/git-core/
>
> This seems to break existing hooks, or at least old repositories can
> be stuck using an old version of git-sh-setup in those hooks.
Honestly speaking, I do not think this patch is worth it.
People who care deeply enough should just use gitexecdir that is
separate from bindir.
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Luben Tuikov @ 2006-12-08 20:45 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <elcegl$qfh$1@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
> > Pazu <pazu@pazu.com.br> writes:
> >
> >> # Please enter the commit message for your changes.
> >> # (Comment lines starting with '#' will not be included)
> >> # On branch refs/heads/next
> >> # Updated but not checked in:
> >> # (will commit)
> >> #
> >> # modified: perl/Makefile
> >> # modified: var.c
> >>
> >> Here's where the magic would happen. Removing the line "modified: var.c" would
> >> remove var.c from this commit. Of course, the template message should be
> >> modified to tell the user he can do that.
> >>
> >> So, what do you think about this?
> >
> > Personally, I would refuse to use such a modified git, because
> > often the first thing I would do in the commit log buffer is
> > check the listed files and remove the '# ...' lines while
> > typing. I do not want that to affect the set of changes I
> > staged in any way.
> >
> > But maybe that is just me.
>
> I was to raise the same objection.
>
> But this can be solved by using magic _only_ if the template with exception
> of "modified:" lines matches, and if there is at least one file
> in "modified:" section.
I raise the same objection as Junio.
This is how perforce does it*, and while it is useful, git is NOT perforce,
and I agree with Junio and Jakub.
If you want to commit only few files, update the index for only
the ones you want to commit. If you did update the index for all
of them, "git-read-tree -m -i HEAD" is your friend.
Luben
* The reason being is that there is no "index-cache" and the commit
message needs to be scanned to determine which of the edited files
you actually intend to commit to the server at this time.
^ permalink raw reply
* Re: Problem compiling: that perl thing again
From: Junio C Hamano @ 2006-12-08 20:49 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <805469.91804.qm@web31805.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Over the last 2 months each time I pull, check out next and compile,
> I'm seeing _some_ kind of problem with compiling the perl section
> of git. Sometimes git-reset --hard, or a fresh checkout, or git-clean
> resolve the situation. But not this time.
> ...
> So, where is "perl.mak"?
This particular breakage cannot be "last two months", but there
was a recent breakage by commit f848718a last week on the 'master'
branch.
---
Junio C Hamano <junkio@cox.net> writes:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
>>>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> Alex> Strange. You seem to have the old, generated Makefile you perl/
>> Alex> directory. Haven't your pull failed? If so, I suspect that
>>
>> Alex> rm perl/Makefile
>> Alex> git reset --hard
>> Alex> git pull git...
>>
>> I ended up having to do another reset afterward.
>>
>> Definitely something went weird when Makefile was removed
>> from .gitignore.
>
> Yes, perl/Makefile is getting overwritten by what Makefile.PL
> generates. I thought the point of Alex's patch was to have it
> muck with perl.mak and leave the tracked Makefile alone?
Now, I am CLUELESS about what MakeMaker does, but would this
help?
---
diff --git a/perl/Makefile b/perl/Makefile
index bd483b0..099beda 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,7 +29,7 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
- '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+ '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
endif
# this is just added comfort for calling make directly in perl dir
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index de73235..4168775 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -24,5 +24,6 @@ WriteMakefile(
NAME => 'Git',
VERSION_FROM => 'Git.pm',
PM => \%pm,
+ MAKEFILE => 'perl.mak',
%extra
);
^ permalink raw reply related
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Han-Wen Nienhuys @ 2006-12-08 20:50 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0612081111h53699ecbr5fb72e17526993d5@mail.gmail.com>
Nguyen Thai Ngoc Duy escreveu:
> On 12/9/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>>
>> git-sh-setup isn't a 'normal' binary, in that it should be called by
>> bash only and not run in a subshell. Therefore, it should not be
>> installed
>> in a executable directory, but rather in $prefix/share/git-core/
>
> Executables should not go to $prefix/share I think. Maybe $prefix/libexec?
Yes, correct. Will change.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Santi Béjar @ 2006-12-08 20:52 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612082012.19167.Josef.Weidendorfer@gmx.de>
On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> Clarify the meaning of branch.*.merge option and add a similar
> branch.*.localmerge option, which can be used to specify a local
> tracking branch to be merged by default.
>
> Previously, if branch.*.merge was specified but did not match any
> ref, the message "No changes." was not really helpful regarding
> the misconfiguration. This now gives a warning.
>
> The value of branch.*.merge can be a list to get an octopus
> merge. I chose the same way for branch.*.localmerge, and if
> you specify both options, the octopus merge will have even
> more parents ;-)
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Ack for the documentation part. But the localmerge part is almost
equivalent to my patch to allow the branch.<name>.remote equal to ".".
^ permalink raw reply
* reexporting git repository via git-daemon
From: Arkadiusz Miskiewicz @ 2006-12-08 21:12 UTC (permalink / raw)
To: git
Hi,
I have weird problem wit git (1.4.4.2).
git --bare clone git://git.kernel.org/pub/scm/git/git.git
fetches everything correctly;
$ cd /tmp
$ git clone /gitroot/home/gitrepo/git
remote: Generating pack...
remote: Done counting 33527 objects.
remote: Deltifying 33527 objects.
remote: 100% (33527/33527) done
Indexing 33527 objects.
remote: Total 33527, written 33527 (delta 23162), reused 33527 (delta 23162)
100% (33527/33527) done
Resolving 23162 deltas.
100% (23162/23162) done
Checking files out...
100% (743/743) done
$
also correctly fetched. The problem begins with exporting that cloned repo
once again via git-daemon:
$ git clone git://git.my-server/git
fatal: unexpected EOF
fetch-pack from 'git://git.my-server/git' failed.
strace on git-daemon side:
[...]
18241 lstat("refs/tags/v1.4.1-rc2", {st_mode=S_IFREG|0644, st_size=41, ...}) =
0
18241 open("refs/tags/v1.4.1-rc2", O_RDONLY) = 7
18241 read(7, "33c9db007159db11c1ad5fa7101ea95853740acf\n", 255) = 41
18241 close(7) = 0
18241 write(1, "004233c9db007159db11c1ad5fa7101ea95853740acf
refs/tags/v1.4.1-rc2\n", 66) = 66
18241 write(1, "0045abc02670169cee9541793a86324a014272ca8ed5
refs/tags/v1.4.1-rc2^{}\n", 69) = 69
18241 stat("refs/tags/v1.4.1.1", {st_mode=S_IFREG|0644, st_size=41, ...}) = 0
18241 lstat("refs/tags/v1.4.1.1", {st_mode=S_IFREG|0644, st_size=41, ...}) = 0
18241 open("refs/tags/v1.4.1.1", O_RDONLY) = 7
18241 read(7, "8419a453dc088b25b63ab1746d3d7e679caf686d\n", 255) = 41
18241 close(7)
18241 write(1, "00408419a453dc088b25b63ab1746d3d7e679caf686d
refs/tags/v1.4.1.1\n", 64) = 64
18241 write(2, "fatal: ", 7) = 7
18241 write(2, "corrupted pack
file ./objects/pack/pack-0bb22295a585ac173504a2f8dfb3e31e074a8715.pack", 85)
= 85
18241 write(2, "\n", 1)
100% repeatable at this moment. Any ideas?
ps. verification for initial git://git.kernel.org/pub/scm/git/git.git clone:
git]$ git --bare fsck-objects
fatal: Not a git repository: '/gitroot/home/gitrepo/git'
git]$ git fsck-objects
git]$
--
Arkadiusz Miśkiewicz PLD/Linux Team
^ permalink raw reply
* Re: Problem compiling: that perl thing again
From: Luben Tuikov @ 2006-12-08 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvekmgljm.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Over the last 2 months each time I pull, check out next and compile,
> > I'm seeing _some_ kind of problem with compiling the perl section
> > of git. Sometimes git-reset --hard, or a fresh checkout, or git-clean
> > resolve the situation. But not this time.
> > ...
> > So, where is "perl.mak"?
>
> This particular breakage cannot be "last two months", but there
> was a recent breakage by commit f848718a last week on the 'master'
> branch.
Not this particular one, but others in that area (perl make).
> Now, I am CLUELESS about what MakeMaker does, but would this
> help?
>
> ---
> diff --git a/perl/Makefile b/perl/Makefile
> index bd483b0..099beda 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -29,7 +29,7 @@ $(makfile): ../GIT-CFLAGS Makefile
> echo ' echo $(instdir_SQ)' >> $@
> else
> $(makfile): Makefile.PL ../GIT-CFLAGS
> - '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
> + '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
> endif
>
> # this is just added comfort for calling make directly in perl dir
> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
> index de73235..4168775 100644
> --- a/perl/Makefile.PL
> +++ b/perl/Makefile.PL
> @@ -24,5 +24,6 @@ WriteMakefile(
> NAME => 'Git',
> VERSION_FROM => 'Git.pm',
> PM => \%pm,
> + MAKEFILE => 'perl.mak',
> %extra
> );
Yes, this helps. Please commit.
Thanks,
Luben
^ permalink raw reply
* Re: [PATCH 1/5] rerere: avoid misrecording on a skipped or aborted rebase/am
From: Eric Wong @ 2006-12-08 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ix2i0e5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > +if (@ARGV && $ARGV[0] eq 'clear') {
> > + for my $path (keys %merge_rr) {
> > + my $name = $merge_rr{$path};
> > + if (-d "$rr_dir/$name") {
> > + rmtree(["$rr_dir/$name"]);
> > + }
> > + }
> > + unlink $merge_rr;
> > + exit 0;
> > +}
>
> Come to think of it, I am not sure about this one. Don't you
> need to make sure that there is no existing resolution before
> removing it? In other words, shouldn't the removal be like this?
>
> if (-d "$rr_dir/$name" && ! -f "$rr_dir/$name/postimage") {
> rmtree(["$rr_dir/$name"]);
> }
Yes. However, it seems unlikely, that MERGE_RR would point to something
that has a postimage. I suppose that a machine could crash or a user
could've hit ^C at the correct millisecond that would cause rerere to
not update MERGE_RR correctly.
Updated patches on the way (leaving out the status updates).
--
^ permalink raw reply
* [PATCH] rerere: add clear, diff, and status commands
From: Eric Wong @ 2006-12-08 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20061208212830.GB13944@localdomain>
git-am and git-rebase will be updated to use 'clear', and
diff/status can be used to aid the user in tracking progress in
the resolution process.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-rerere.txt | 27 +++++++++++++++++++++++++--
git-rerere.perl | 25 +++++++++++++++++++++++++
2 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 8b6b651..22494b2 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -7,8 +7,7 @@ git-rerere - Reuse recorded resolve
SYNOPSIS
--------
-'git-rerere'
-
+'git-rerere' [clear|diff|status]
DESCRIPTION
-----------
@@ -167,6 +166,30 @@ would conflict the same way the test merge you resolved earlier.
`git-rerere` is run by `git rebase` to help you resolve this
conflict.
+COMMANDS
+--------
+
+Normally, git-rerere is run without arguments or user-intervention.
+However, it has several commands that allow it to interact with
+its working state.
+
+'clear'::
+
+This resets the metadata used by rerere if a merge resolution is to be
+is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
+[--skip|--abort] will automatcally invoke this command.
+
+'diff'::
+
+This displays diffs for the current state of the resolution. It is
+useful for tracking what has changed while the user is resolving
+conflicts. Additional arguments are passed directly to the system
+diff(1) command installed in PATH.
+
+'status'::
+
+Like diff, but this only prints the filenames that will be tracked
+for resolutions.
Author
------
diff --git a/git-rerere.perl b/git-rerere.perl
index d3664ff..2703d01 100755
--- a/git-rerere.perl
+++ b/git-rerere.perl
@@ -172,6 +172,31 @@ sub merge {
-d "$rr_dir" || exit(0);
read_rr();
+
+if (my $arg = shift @ARGV) {
+ if ($arg eq 'clear') {
+ for my $path (keys %merge_rr) {
+ my $name = $merge_rr{$path};
+ if (-d "$rr_dir/$name" && ! -f "$rr_dir/$name/postimage") {
+ rmtree(["$rr_dir/$name"]);
+ }
+ }
+ unlink $merge_rr;
+ } elsif ($arg eq 'status') {
+ for my $path (keys %merge_rr) {
+ print $path, "\n";
+ }
+ } elsif ($arg eq 'diff') {
+ for my $path (keys %merge_rr) {
+ my $name = $merge_rr{$path};
+ system(qw/diff/, @ARGV,
+ '-L', "a/$path", '-L', "b/$path",
+ "$rr_dir/$name/preimage", $path);
+ }
+ }
+ exit 0;
+}
+
my %conflict = map { $_ => 1 } find_conflict();
# MERGE_RR records paths with conflicts immediately after merge
--
1.4.4.2.g860f4
^ permalink raw reply related
* [PATCH] rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
From: Eric Wong @ 2006-12-08 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11656133963055-git-send-email-normalperson@yhbt.net>
Data in rr-cache isn't valid after a patch application is
skipped or and aborted, so our next commit could be misrecorded
as a resolution of that skipped/failed commit, which is wrong.
git-am --skip, git-rebase --skip/--abort will automatically
invoke git-rerere clear to avoid this.
Also, since git-am --resolved indicates a resolution was
succesful, remember to run git-rerere to record the resolution
(and not surprise the user when the next commit is made).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-am.sh | 8 ++++++++
git-rebase.sh | 8 ++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index afe322b..5df6787 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -246,6 +246,10 @@ last=`cat "$dotest/last"`
this=`cat "$dotest/next"`
if test "$skip" = t
then
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git-rerere clear
+ fi
this=`expr "$this" + 1`
resume=
fi
@@ -408,6 +412,10 @@ do
stop_here_user_resolve $this
fi
apply_status=0
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git rerere
+ fi
;;
esac
diff --git a/git-rebase.sh b/git-rebase.sh
index 25530df..2b4f347 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -139,6 +139,10 @@ do
--skip)
if test -d "$dotest"
then
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git-rerere clear
+ fi
prev_head="`cat $dotest/prev_head`"
end="`cat $dotest/end`"
msgnum="`cat $dotest/msgnum`"
@@ -157,6 +161,10 @@ do
exit
;;
--abort)
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git-rerere clear
+ fi
if test -d "$dotest"
then
rm -r "$dotest"
--
1.4.4.2.g860f4
^ permalink raw reply related
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Junio C Hamano @ 2006-12-08 21:38 UTC (permalink / raw)
To: Santi Béjar
Cc: Josef Weidendorfer, Junio C Hamano, Aneesh Kumar K.V,
Johannes Schindelin, git
In-Reply-To: <8aa486160612081252t1e245104x58c8a6654d887af5@mail.gmail.com>
"Santi Béjar" <sbejar@gmail.com> writes:
> On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>> Clarify the meaning of branch.*.merge option and add a similar
>> branch.*.localmerge option, which can be used to specify a local
>> tracking branch to be merged by default.
>>
>> Previously, if branch.*.merge was specified but did not match any
>> ref, the message "No changes." was not really helpful regarding
>> the misconfiguration. This now gives a warning.
>>
>> The value of branch.*.merge can be a list to get an octopus
>> merge. I chose the same way for branch.*.localmerge, and if
>> you specify both options, the octopus merge will have even
>> more parents ;-)
>>
>> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
>
> Ack for the documentation part. But the localmerge part is almost
> equivalent to my patch to allow the branch.<name>.remote equal to ".".
I am not so sure about the "localmerge" stuff anymore.
What convenience would it buy us (including but not limited to
new people), and if there is any, would that outweigh the
potential confusion factor to have two different configuration
variables that do exactly the same thing whose sole difference
is which side of the fetched branch namespace it uses to specify
the merge source?
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Josef Weidendorfer @ 2006-12-08 21:39 UTC (permalink / raw)
To: Santi Béjar
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <8aa486160612081252t1e245104x58c8a6654d887af5@mail.gmail.com>
On Friday 08 December 2006 21:52, Santi Béjar wrote:
> On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > Clarify the meaning of branch.*.merge option and add a similar
> > branch.*.localmerge option, which can be used to specify a local
> > tracking branch to be merged by default.
> >
> > Previously, if branch.*.merge was specified but did not match any
> > ref, the message "No changes." was not really helpful regarding
> > the misconfiguration. This now gives a warning.
> >
> > The value of branch.*.merge can be a list to get an octopus
> > merge. I chose the same way for branch.*.localmerge, and if
> > you specify both options, the octopus merge will have even
> > more parents ;-)
> >
> > Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
>
> Ack for the documentation part. But the localmerge part is almost
> equivalent to my patch to allow the branch.<name>.remote equal to ".".
Interesting. I did not have a look at your patch.
The support for the "branch.*.localmerge" option is one step to be
able to support a remote ".". So of course, it probably is similar.
I even would say that "." as remote now actually makes sense as
logical extension.
However, what would you change in the implementation part of my patch?
^ permalink raw reply
* Re: [PATCH] rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
From: Jakub Narebski @ 2006-12-08 21:44 UTC (permalink / raw)
To: git
In-Reply-To: <1165613397460-git-send-email-normalperson@yhbt.net>
Eric Wong wrote:
Just one comment:
> + if test -d "$GIT_DIR/rr-cache"
> + then
> + git-rerere clear
> + fi
> this=`expr "$this" + 1`
> resume=
> fi
> @@ -408,6 +412,10 @@ do
> stop_here_user_resolve $this
> fi
> apply_status=0
> + if test -d "$GIT_DIR/rr-cache"
> + then
> + git rerere
> + fi
Why do you use once "git-rerere", and another time "git rerere"?
Shouldn't scripts always use git-command form?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Jakub Narebski @ 2006-12-08 21:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6vagja6.fsf@assigned-by-dhcp.cox.net>
<opublikowany i wysłany>
Junio C Hamano wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
>> On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>>> Clarify the meaning of branch.*.merge option and add a similar
>>> branch.*.localmerge option, which can be used to specify a local
>>> tracking branch to be merged by default.
>>>
>>> Previously, if branch.*.merge was specified but did not match any
>>> ref, the message "No changes." was not really helpful regarding
>>> the misconfiguration. This now gives a warning.
[...]
>>
>> Ack for the documentation part. But the localmerge part is almost
>> equivalent to my patch to allow the branch.<name>.remote equal to ".".
>
> I am not so sure about the "localmerge" stuff anymore.
>
> What convenience would it buy us (including but not limited to
> new people), and if there is any, would that outweigh the
> potential confusion factor to have two different configuration
> variables that do exactly the same thing whose sole difference
> is which side of the fetched branch namespace it uses to specify
> the merge source?
What about my proposal to allow for full refspec, or :<localbranch>
to be specified? I.e. allow all the following forms:
branch.<name>.merge = refs/heads/<remotebranch>
branch.<name>.merge = refs/heads/<remotebranch>:refs/remotes/<remote>/<localbranch>
branch.<name>.merge = :refs/remotes/<remote>/<localbranch>
By the way, if branch.*.remote is equal to ".", remote branch is
local branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
From: Eric Wong @ 2006-12-08 21:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <elcm6u$l8t$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Eric Wong wrote:
>
> Just one comment:
>
> > + if test -d "$GIT_DIR/rr-cache"
> > + then
> > + git-rerere clear
> > + fi
> > this=`expr "$this" + 1`
> > resume=
> > fi
> > @@ -408,6 +412,10 @@ do
> > stop_here_user_resolve $this
> > fi
> > apply_status=0
> > + if test -d "$GIT_DIR/rr-cache"
> > + then
> > + git rerere
> > + fi
>
> Why do you use once "git-rerere", and another time "git rerere"?
> Shouldn't scripts always use git-command form?
Yes. Or at least I remember git-command form being preferred.
I don't think I've been entirely consistent in the things I've
written, and my shell history is just as inconsistent :x
--
^ permalink raw reply
* [RFC] Light-weight checkouts via ".gitlink"
From: Josef Weidendorfer @ 2006-12-08 21:52 UTC (permalink / raw)
To: git
Hi,
when I recently thought about submodule support, I had the
idea that it is easier to get it by going in small,
incremental steps, introducing usefull subfeatures on their
on while on it.
The following is one outcome of this, a proposal for
light-weight checkouts of git branches, without the need
to have to full repository in a .git subdirectory, but
the just have a file .gitlink is simple as possible, which
manages the link to the real repository.
Of course, this feature is tailored to support checkouts of
submodules as being such light-weight checkouts themself.
The current proposal just says that light-weight checkouts
should be ignored when existing inside of another checkout.
For real submodule support, we would want to be able the
do a "git add" on these light-weight checkouts (which of
course are bound to some commit), and on "git commit", this
would add a "submodule object" at this place into the tree
of the outer repository.
Comments?
Josef
============================================================
Support for multiple external light-weight checkouts
aka ".gitlink" proposal
Main ideas behind light-weight checkouts
----------------------------------------
Make submodules easier to implement by separating
part of the needed infrastructure into a independent,
yet useful feature
(1) Allow to separate a branch checkout from its repository location
on the local filesystem. This minimally needs to be only _one_ file,
called ".gitlink" here. One should be able to move the
checkout directory around (within some limits) without breaking
the link to its "base" repository.
We want this later for submodule checkouts inside of a supermodule
checkout: (a) to not loose the objects+index+HEAD if the user
removes the whole checkout to remove the submodule in next
supermodule commit; (b) to allow for moving submodules around
between supermodule commits.
This can be implemented with a small script reading .gitlink and setting
up $GITDIR and $GIT_INDEX_FILE accordingly. However, there should be
a further environment variable to use a file for HEAD ($GIT_HEAD_FILE?).
Interpretation of the link to the base directory has to be a little smart,
ie. by prefixing a relative path with as many ".." as needed to find a
git repository.
(2) Light-weight checkouts should work inside of another
checkout, be it a normal or a light-weight checkout itself.
The subdirectory of the light-weight checkout has to be ignored
in the outer checkout (at least by default).
This is needed to be able to use light-weight checkouts for submodels,
as these should be checked out inside of another checkout (even
inside of another submodule checkout for hierarchical submodules).
This can be implemented by enhancing git to ignore any subdirectory which
has a file .gitlink in it.
Example usage
-------------
Keep a checkout of the todo branch of git.git inside of the checkout of
any other branch (or fully outside). You should be able to use all the normal
git commands inside of this directory (commit etc).
Something like inside of e.g. a master checkout of git.git:
make todo
cd todo
touch .gitlink
git checkout todo
The .gitlink file can be empty in this case when we make the smart lookup of
the base repository do the right thing with a default of an emtpy relative path.
Another usage is to keep all your git repositories (looking like bare ones)
in one place, e.g. below $HOME/git-repositories/, and have the the checkouts
you are working in at another place, without the need for setting $GITDIR etc
for this.
Some thoughts about implementation
----------------------------------
As we need our own index and HEAD for any light-weight checkout, we
can choose a subdirectory of .git of the base repository to store a full,
independent working GITDIR on its own. It would default to linking the
objects and refs namespace to the base repository, but for submodules,
it *can* have its own object database and refs namespace; it just would
be locateable via the GITDIR of the base repository.
"Locateable" means that we need a name for different light-weight
checkouts. The name can be determined from the relative position of
the light-weight checkout to its base repository, or could be fixed
and specified in the .gitlink file.
Example for an light-weight checkout with name "mywork", linking to
the (bare) base repository "base":
base.git/external/mywork/HEAD
base.git/external/mywork/index
base.git/external/mywork/refs -> ../../../refs
base.git/external/mywork/objects -> ../../../objects
A light-weight checkout in a sibling directory to base.git needs
the relative path to its own .git directory:
"../base.git/external/mywork".
This can be split up in two things:
- relative path to base repository
- a name for this light-weight checkout
One has to be able to get this out of the content of the .gitlink file.
Proposal for .gitlink entries (one line per entry)
--------------------------------------------------
* Gitdir = "<Path to base git repository>"
Optional.
An absolute or relative path to the base git repository.
With relative path, a heuristic is used to find the
git directory: the path will be prefixed by as
many "../" as needed, and ".git" or .gitlink appended.
The value defaults to an empty relative path, which
will check all parent directories for a .git subdirectory.
* Name: <explicit name for this checkout>
Optional.
Git uses this name to find its own GITDIR in the GITDIR
of the base repository. If not specified, the name defaults
to the relative path of the light-weight checkout from
the base directory, stripping any ".." in front.
For the "mywork" example above, we could have a checkout
directory, sibling to "base.git" and called "mywork".
For the .gitlink file inside, it is enough to specify
Gitdir = base
Because the search heuristic will find the base repository
at real relative path "../base.git". Further, relative
path of the checkout from the base repository is "../mywork",
giving the name "mywork".
When moving the checkout into another directory, it's name
would change if not explicitly specified in the .gitlink
file. For submodules, this could be the wanted semantic.
However, with changing name, we have possibly lost our
index and HEAD.
A solution for this could be to always store a copy of HEAD
into .gitlink, or even have a "Head:" .gitlink entry itself
as HEAD.
============================================================
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Josef Weidendorfer @ 2006-12-08 22:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Santi Béjar, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <7vr6vagja6.fsf@assigned-by-dhcp.cox.net>
On Friday 08 December 2006 22:38, Junio C Hamano wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> >> Clarify the meaning of branch.*.merge option and add a similar
> >> branch.*.localmerge option, which can be used to specify a local
> >> tracking branch to be merged by default.
>
> I am not so sure about the "localmerge" stuff anymore.
>
> What convenience would it buy us (including but not limited to
> new people), and if there is any, would that outweigh the
> potential confusion factor to have two different configuration
> variables that do exactly the same thing whose sole difference
> is which side of the fetched branch namespace it uses to specify
> the merge source?
I just came up with a concrete patch.
I am not saying that this is the only true solution.
Actually, Jakubs one with allowing arbitrary refspecs is nice.
The only problem is that it is not consistent which refspec
shortcuts otherwise, or?
However, you should take the documentation part and the warning
when there is no match .
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Josef Weidendorfer @ 2006-12-08 22:10 UTC (permalink / raw)
To: ltuikov; +Cc: Jakub Narebski, git
In-Reply-To: <360959.72234.qm@web31809.mail.mud.yahoo.com>
On Friday 08 December 2006 21:45, Luben Tuikov wrote:
> This is how perforce does it*, and while it is useful, git is NOT perforce,
> and I agree with Junio and Jakub.
However, the idea itself is not bad. AFAIK, cogito does it this way.
It could be done as separate command, e.g. "git add --interactive",
and would only update the index.
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Santi Béjar @ 2006-12-08 22:15 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612082239.38423.Josef.Weidendorfer@gmx.de>
On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Friday 08 December 2006 21:52, Santi Béjar wrote:
> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > > Clarify the meaning of branch.*.merge option and add a similar
> > > branch.*.localmerge option, which can be used to specify a local
> > > tracking branch to be merged by default.
> > >
> > > Previously, if branch.*.merge was specified but did not match any
> > > ref, the message "No changes." was not really helpful regarding
> > > the misconfiguration. This now gives a warning.
> > >
> > > The value of branch.*.merge can be a list to get an octopus
> > > merge. I chose the same way for branch.*.localmerge, and if
> > > you specify both options, the octopus merge will have even
> > > more parents ;-)
> > >
> > > Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
> >
> > Ack for the documentation part. But the localmerge part is almost
> > equivalent to my patch to allow the branch.<name>.remote equal to ".".
>
> Interesting. I did not have a look at your patch.
> The support for the "branch.*.localmerge" option is one step to be
> able to support a remote ".". So of course, it probably is similar.
> I even would say that "." as remote now actually makes sense as
> logical extension.
>
> However, what would you change in the implementation part of my patch?
I would only take the documentation part (without the localmerge part)
and the test for the warning.
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Jakub Narebski @ 2006-12-08 22:18 UTC (permalink / raw)
To: git
In-Reply-To: <200612082252.31245.Josef.Weidendorfer@gmx.de>
A few (very few) comments:
Josef Weidendorfer wrote:
> This can be implemented by enhancing git to ignore any subdirectory which
> has a file .gitlink in it.
If I remember correctly, while git ignores .git, it does not ignore
by default (i.e. without entry in either GIT_DIR/info/excludes, or
.gitignore) the directory which has .git directory in it.
And that should not change for .gitlink. You can always add
.gitignore file with * .* patterns in it (ignore all).
> * Gitdir = "<Path to base git repository>"
[...]
> * Name: <explicit name for this checkout>
Why use once "key = value", once "key: value" form? Better to stick
with one. I Would prefer "key = value" one.
GIT_DIR = path to base git repository
it is equivalent to setting the following:
GIT_INDEX_FILE = path to index file
GIT_OBJECT_DIRECTORY = path to object directory
GIT_HEAD_FILE = path to HEAD file
GIT_REFS_DIRECTORY = path to refs directory
NAME = name
should match "name subdirectory" entry in modules file in superproject.
Perhaps instead of adding arbitrary number of .. in front of relative
path, we better use some magic, like ... for finding somewhere up?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Collection of stgit issues and wishes
From: Yann Dirson @ 2006-12-08 22:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
Here is the remaining of my queue of stgit issues and ideas noted
in the last months. A number of items in the "wishlist" section is
really here to spawn discussion. Maybe some of them should end up
in the TODO list.
bugs:
- "show" still shows previous patch, after pushing resulted in empty patch
(after solving conflict, when "refresh" then has nothing to do)
- "stg import" leaves empty patch on the stack after failed patch application
- "push --undo" should restore series order
- "import --strip" is too eager (eg. eats numeric prefix when we only
want to strip a .diff suffix). Probably better symetry with export
flags would be useful.
- "push" fails with "Unknown patch name:" when asked to push a patch
already applied
- "stg fold" usage does not tell what <file> is used for
- "patches -d" may be confused by files added then removed (below,
file added to platform-v0, removed in rm-junk, problem encountered on
2006-08-14, probably on 0.10):
|$ stg patches include/linux/mtd/nand.h.old
|platform-v0
|ieee-lct-bouton
|rm-junk
|$ stg patches include/linux/mtd/nand.h.old -d
|-------------------------------------------------------------------------------
|platform-v0
|-------------------------------------------------------------------------------
|Kernel for V0 platform
|---
|
|stg patches: ['git-diff-tree', '-p',
|'7a9c28b56f5f210e11632388ffb554ae2cb04492',
|'a8e874d6090bc6274cadcff64faf7cff151b9b5c', 'include/linux/mtd/nand.h.old']
|failed (fatal: ambiguous argument 'include/linux/mtd/nand.h.old': unknown
|revision or path not in the working tree.
|Use '--' to separate paths from revisions)
usability problems:
- "refresh" should display .git/conflicts if any ?
- patches/*/*.log branches could be better named as patchlogs/*/*
(easier to filter reliably)
- "stg show" should catch inexistant patch instead of saying "Unknown
revision: that-patch^{commit}"
- "clean" should give enough info for the user to locate any problem
(eg. conflict with files removed from revision control), eg. with a
"popping to ..." message
- "stg fold" should allow to pass -C<n> to git-apply: context mismatch
currently makes folding unnecessarily hard
|$ stg show d-lessdebug | filterdiff -#3 | stg fold
|Folding patch from stdin...stg fold: Patch does not apply cleanly
|$ stg show d-lessdebug | filterdiff -#3 | patch -p1
|patching file drivers/ieee1394/gp2lynx.c
|Hunk #1 succeeded at 2074 with fuzz 2 (offset -96 lines).
- "stg pick patch@branch" needs non-intuitive "stg push --undo" to cancel :
add "stg pick --undo ?"
- "stg pick --fold" needs even less-intuitive "stg push --undo && stg
push" or "stg status --reset"
wishlist and wild ideas:
- lacks syntax for "(n) patches before/after X"
- "stg goto <current>" causes IndexError exception
- needs series logging in addition to patch logging
- "stg pull --undo" to move the stack base back to previous place
(esp. useful after "push" detected a conflict we don't want to handle
right now)
- single-arg "stg rename" to rename current patch ?
- lacks undo for "pick --fold"
- "sink" or "burry" as opposite to "float" (possibly with a target
patch)
- lacks "pick --patch=XXX" to pick by name
- "stg clean" could take a list of patches, to allow being used in scripts
- "stg fold" lacks --reverse
- interactive merge tools could only be called automatically after
failed merge, instead of requiring not-so-intuitive "resolved -i"
- needs a config example to call ediff via gnuserv (possibly sending
several merges at a time, making use of the session registry)
- shortcuts (st -> status, etc.), possibly making use of the git alias
system ?
- "stg fold" should allow to run a merge (insert conflict markers, or
even just output a .rej patch somewhere)
- support for atomicity of complex transactions (stg begin/snapshot,
rollback, commit/finish - possibly with a transaction name so nesting would
just work)
- support for pure patch reordering when a move causes conflicts.
Maybe a way to start a transaction while declaring the patch range
which has to be reordered, ensuring that finalising the transaction
would end with the desired tree state unchanged.
- mark patches as deactivated (float above all unapplied ones), so
even "push -a" would not push them
- "stg diff" should allow to use diff flags like -w or -b (GIT_DIFF_OPTS
does not work)
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-08 22:27 UTC (permalink / raw)
To: git
In-Reply-To: <20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net>
Here are some issues which are a bit annoying for me:
- make "stg help" (without command name) equivalent to "stg --help"
- stg new lacks --sign option (I have to remember to do this during
"stg refresh").
Stacked GIT 0.11
git version 1.4.4.1
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Junio C Hamano @ 2006-12-08 22:34 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Santi Béjar, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612082301.57037.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Friday 08 December 2006 22:38, Junio C Hamano wrote:
>> "Santi Béjar" <sbejar@gmail.com> writes:
>>
>> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>> >> Clarify the meaning of branch.*.merge option and add a similar
>> >> branch.*.localmerge option, which can be used to specify a local
>> >> tracking branch to be merged by default.
>>
>> I am not so sure about the "localmerge" stuff anymore.
>>
>> What convenience would it buy us (including but not limited to
>> new people), and if there is any, would that outweigh the
>> potential confusion factor to have two different configuration
>> variables that do exactly the same thing whose sole difference
>> is which side of the fetched branch namespace it uses to specify
>> the merge source?
>
> I just came up with a concrete patch.
> I am not saying that this is the only true solution.
I admit that I do not use branch.*.merge and I do not know what
people find lacking in what Santi did in late September with
commit 5372806. What problem are we trying to solve (not a
rhetorical question -- I am truly lost here)? Is it only a
confusion between remote and local, or is there something that
cannot be expressed with the current scheme?
> Actually, Jakubs one with allowing arbitrary refspecs is nice.
> The only problem is that it is not consistent which refspec
> shortcuts otherwise, or?
Actually I had a quite opposite reaction about allowing src:dst
notation there. Does it solve any real problem? It is unclear
to me. On the other hand, it gives a false impression that it
can be used instead of remote.*.fetch to copy the remote branch
into local tracking branch, and raises other questions such as
what should happen when you have both, i.e. src:dst is given to
both remote.*.fetch and branch.*.merge, and they do not agree.
Which means it only adds to the confusion.
So I do not think it is worth spending brain cycles talking
about that particular one; it does not even have a patch to
implement it.
But you have a concrete patch, and if it is fixing a real
problem, then that is worth talking about. I just do not know
if a problem exists, other than that people can get confused and
write local tracking branch name by mistake when it should be
remote branch name.
^ 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