* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Michael J Gruber @ 2009-12-08 16:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <hflc82$sf8$1@ger.gmane.org>
Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
> Michael J Gruber wrote:
>
>> +decrypt_color () {
>> + sed \
>> + -e 's/.\[1m/<WHITE>/g' \
>> + -e 's/.\[31m/<RED>/g' \
>> + -e 's/.\[32m/<GREEN>/g' \
>> + -e 's/.\[34m/<BLUE>/g' \
>> + -e 's/.\[m/<RESET>/g'
>> +}
>
> Shouldn't this be better in test-lib.sh, or some common lib
> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
> in naming here)?
Well, so far it's used in two places (and somewhat differently). I would
say test-libification starts at 3 :)
Michael
^ permalink raw reply
* [PATCH 2/2] gitk-git: have make uninstall also remove empty directories
From: Jan Nieuwenhuizen @ 2009-12-08 15:23 UTC (permalink / raw)
To: git
The default Git install performs a multi-rooted install in $HOME,
which makes manual removal somewhat cumbersome.
The directories created by the installation should be removed if
they are empty.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
gitk-git/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
--
1.6.5.2.182.g1a756
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply related
* [PATCH 1/2] Add/resurrect make uninstall target
From: Jan Nieuwenhuizen @ 2009-12-08 15:23 UTC (permalink / raw)
To: git
Uninstall is a common make target that users may expect to be present,
e.g. it is provided automatically by automake.
The default Git install performs a multi-rooted install in $HOME,
which makes manual removal somewhat cumbersome.
The uninstall target was not present in the toplevel makefile,
only a few other makefiles had partial uninstall targets.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
Makefile | 18 +++++++++++++++++-
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 4a1e5bc..b9ef172 100644
--- a/Makefile
+++ b/Makefile
@@ -1842,7 +1842,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1921,7 +1937,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.5.2.182.g1a756
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply related
* Re: Git GUI client SmartGit released
From: Alexander Kitaev @ 2009-12-08 14:17 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Shawn O. Pearce, git
In-Reply-To: <4B16D8F8.90804@syntevo.com>
Hello,
>> I'm curious, did you guys replace JSch because its a pile of junk?
Above statement describes the reason behind my decision to use Trilead
SSH instead of JSCH more or less precisely.
In particular, version of JSCH we were using, used to work extremely
unreliable in case multiple channels within same connection were used
simultaneously. And code quality of JSCH didn't allow me to fix this and
other JSch issues in reasonable time.
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!
Marc Strapetz wrote:
>> I noticed you use JGit and the Trilead SSH client.
>>
>> I'm curious, did you guys replace JSch because its a pile of junk?
>> Did you patch JGit to use Trilead SSH instead of JSch? If so,
>> would you be interested in contributing that change back to JGit?
>> I'm rather fed up with JSch... :-)
>
> We currently don't use JGit's transport, but we plant a custom SSH
> client on the git executable which connects back to SmartGit and just
> tunnels SSH data through. Anyway, I can remember that SVNKit was using
> JSch initially and they switched to Trilead because of problems with
> JSch (maybe Alexander in Cc can shed more light on that).
>
> --
> Best regards,
> Marc Strapetz
> =============
> syntevo GmbH
> http://www.syntevo.com
> http://blog.syntevo.com
>
>
>
> Shawn O. Pearce wrote:
>> Marc Strapetz <marc.strapetz@syntevo.com> wrote:
>>> We are proud to announce the general availability of our Git client
>>> SmartGit[1]:
>>>
>>> http://www.syntevo.com/smartgit/index.html
>> Congrats on your release.
>>
>> I noticed you use JGit and the Trilead SSH client.
>>
>> I'm curious, did you guys replace JSch because its a pile of junk?
>> Did you patch JGit to use Trilead SSH instead of JSch? If so,
>> would you be interested in contributing that change back to JGit?
>> I'm rather fed up with JSch... :-)
>>
>
^ permalink raw reply
* Re: [PATCH] Add/resurrect make uninstall target
From: Miklos Vajna @ 2009-12-08 14:57 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1260283831.1856.43.camel@vuurvlieg>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Tue, Dec 08, 2009 at 03:50:31PM +0100, Jan Nieuwenhuizen <janneke-list@xs4all.nl> wrote:
> Makefile | 18 +++++++++++++++++-
> gitk-git/Makefile | 2 ++
> perl/Makefile | 2 +-
> templates/Makefile | 5 +++++
> 4 files changed, 25 insertions(+), 2 deletions(-)
I think the gitk-git one should be a separate patch and then Paul can
apply it to gitk.git.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Add/resurrect make uninstall target
From: Jan Nieuwenhuizen @ 2009-12-08 14:50 UTC (permalink / raw)
To: git
Uninstall is a common make target that users may expect to be present,
e.g. it is provided automatically by automake.
The default Git install performs a multi-rooted installation in $HOME,
which makes manual removing somewhat cumbersome.
The uninstall target was not present in the toplevel makefile,
only a few other makefiles had partial uninstall targets.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
Makefile | 18 +++++++++++++++++-
gitk-git/Makefile | 2 ++
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 4a1e5bc..b9ef172 100644
--- a/Makefile
+++ b/Makefile
@@ -1842,7 +1842,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1921,7 +1937,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.5.2.182.g1a756
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply related
* [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 14:47 UTC (permalink / raw)
To: git, Junio C Hamano
Add --revisions flag to rebase, so that it can be used
to apply an arbitrary range of commits on top
of a current branch.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
I've been wishing for this functionality for a while now,
so here goes. This isn't yet properly documented and I didn't
write a test, but the patch seems to work fine for me.
Any early flames/feedback?
git-rebase.sh | 36 ++++++++++++++++++++++++------------
1 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..d99d04b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,12 +3,13 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto <newbase>] [<upstream>|--root] [<branch>] [--quiet | -q]'
+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto <newbase>] [--revisions <revision range>] [<upstream>|--root] [<branch>] [--quiet | -q]'
LONG_USAGE='git-rebase replaces <branch> with a new branch of the
same name. When the --onto option is provided the new branch starts
out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
It then attempts to create a new commit for each commit from the original
-<branch> that does not exist in the <upstream> branch.
+<branch> that does not exist in the <upstream> branch, or for
+each commit matching <revision range> when the --revisions options is provided.
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
@@ -41,6 +42,7 @@ If you would prefer to skip this patch, instead run \"git rebase --skip\".
To restore the original branch and stop rebasing run \"git rebase --abort\".
"
unset newbase
+unset revisions
strategy=recursive
do_merge=
dotest="$GIT_DIR"/rebase-merge
@@ -291,6 +293,11 @@ do
newbase="$2"
shift
;;
+ --revisions)
+ test 2 -le "$#" || usage
+ revisions="$2"
+ shift
+ ;;
-M|-m|--m|--me|--mer|--merg|--merge)
do_merge=t
;;
@@ -459,12 +466,24 @@ case "$#" in
esac
orig_head=$branch
+if test -z "$revisions"
+then
+ if test -n "$rebase_root"
+ then
+ revisions="$onto..$orig_head"
+ else
+ revisions="$upstream..$orig_head"
+ fi
+ mb=$(git merge-base "$onto" "$branch")
+else
+ mb=""
+fi
+
# Now we are rebasing commits $upstream..$branch (or with --root,
# everything leading up to $branch) on top of $onto
# Check if we are already based on $onto with linear history,
# but this should be done only when upstream and onto are the same.
-mb=$(git merge-base "$onto" "$branch")
if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
# linear history?
! (git rev-list --parents "$onto".."$branch" | sane_grep " .* ") > /dev/null
@@ -489,10 +508,10 @@ if test -n "$diffstat"
then
if test -n "$verbose"
then
- echo "Changes from $mb to $onto:"
+ echo "Changes $revisions:"
fi
# We want color (if set), but no pager
- GIT_PAGER='' git diff --stat --summary "$mb" "$onto"
+ GIT_PAGER='' git diff --stat --summary "$revisions"
fi
# If the $onto is a proper descendant of the tip of the branch, then
@@ -504,13 +523,6 @@ then
exit 0
fi
-if test -n "$rebase_root"
-then
- revisions="$onto..$orig_head"
-else
- revisions="$upstream..$orig_head"
-fi
-
if test -z "$do_merge"
then
git format-patch -k --stdout --full-index --ignore-if-in-upstream \
--
1.6.6.rc1.43.gf55cc
^ permalink raw reply related
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Matthieu Moy @ 2009-12-08 14:39 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Johannes Schindelin, Michael J Gruber,
Michael Haggerty, git
In-Reply-To: <20091208121314.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Teach a new option, --autosquash, to the interactive rebase.
> When the commit log message begins with "!fixup ...", and there
> is a commit whose title begins with the same ...
You should be clearer than "title" here. My understanding is that this
is the _message_ (man git-commit talks about log message or commit
message).
It's a detail, but I could make sense to allow putting something other
than the commit message here, like an object name:
git commit -m "fixup! 66eb61bd"
git commit -m "fixup! HEAD^^"
The last one is a bit tricky, since it should mean "HEAD^^" right
before I did the commit.
All that said, I probably won't be a user of that particular feature
(although I love the new "fixup" command for rebase -i), so don't see
any complaint here, just food for thoughts ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2 3/3] transport-helper.c::push_refs(): emit "no refs" error message
From: Tay Ray Chuan @ 2009-12-08 14:37 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091208223413.98e99d3e.rctay89@gmail.com>
Emit an error message when remote_refs is not set.
This behaviour is consistent with that of builtin-send-pack.c and
http-push.c.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
transport-helper.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 6b1f778..96fc48b 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -321,8 +321,11 @@ static int push_refs(struct transport *transport,
struct child_process *helper;
struct ref *ref;
- if (!remote_refs)
+ if (!remote_refs) {
+ fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
+ "Perhaps you should specify a branch such as 'master'.\n");
return 0;
+ }
helper = get_helper(transport);
if (!data->push)
--
1.6.4.4
^ permalink raw reply related
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Yann Dirson @ 2009-12-08 14:37 UTC (permalink / raw)
To: kusmabite; +Cc: Ferry Huberts, GIT ml
In-Reply-To: <40aa078e0912080623q108b2affk80534ccd5fd7ace3@mail.gmail.com>
On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote:
> On Tue, Dec 8, 2009 at 2:42 PM, Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
> > On 12/08/2009 02:34 PM, Erik Faye-Lund wrote:
> >> On Tue, Dec 8, 2009 at 2:28 PM, Yann Dirson <ydirson@linagora.com> wrote:
> >>> I'm not sure who's at fault here - namely, I can't see any valid
> >>> reason for eclipse to refuse such writes, but I am not sure it is a
> >>> good reason for msysgit would set the hidden bit either. In either
> >>> case, even if only for the short term, I think msysgit should ensure
> >>> that this bit does not get set (possibly circumventing any magic msys
> >>> would do behind its back).
> >>
> >> Setting the config option "core.hidedotfiles" to "false" should
> >> prevent this from happening.
Right, it works much better this way.
> > why isn't this the default?
> >
> > I also experienced this change in behaviour and I thought we would
> > strive to keep the experience the same.
> >
>
> You can follow the discussion here:
> http://code.google.com/p/msysgit/issues/detail?id=288
>
> I believe the reason is something like "because someone suggested it,
> and no one disagreed". Do you have a good argument why it shouldn't be
> the default (other than "it's a change", because changing it back now
> would also be a change)?
Depending on the opinion of the Eclipse guys on this issue about
"writing to hidden files only says 'could not write'", which arguably
could be seen as a bug on their side, we can see changing this
behaviour back to the default on the msysgit side as either a
(possibly temporary) workaround for a known eclipse bug, or as getting
again interoperable with egit.
Note that I did not get time yet to fully investigate the eclipse
status on the issue.
Best regards,
--
Yann
^ permalink raw reply
* [PATCH v2 2/3] transport.c::transport_push(): make ref status affect return value
From: Tay Ray Chuan @ 2009-12-08 14:36 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091208223413.98e99d3e.rctay89@gmail.com>
Use push_had_errors() to check the refs for errors and modify the
return value.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Rewrote this.
transport.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/transport.c b/transport.c
index 12c4423..9b23989 100644
--- a/transport.c
+++ b/transport.c
@@ -875,7 +875,7 @@ int transport_push(struct transport *transport,
int verbose = flags & TRANSPORT_PUSH_VERBOSE;
int quiet = flags & TRANSPORT_PUSH_QUIET;
int porcelain = flags & TRANSPORT_PUSH_PORCELAIN;
- int ret;
+ int ret, err;
if (flags & TRANSPORT_PUSH_ALL)
match_flags |= MATCH_REFS_ALL;
@@ -892,8 +892,11 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_FORCE);
ret = transport->push_refs(transport, remote_refs, flags);
+ err = push_had_errors(remote_refs);
- if (!quiet || push_had_errors(remote_refs))
+ ret |= err;
+
+ if (!quiet || err)
print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
nonfastforward);
--
1.6.4.4
^ permalink raw reply related
* [PATCH v2 1/3] refactor ref status logic for pushing
From: Tay Ray Chuan @ 2009-12-08 14:35 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091208223413.98e99d3e.rctay89@gmail.com>
Move the logic that detects up-to-date and non-fast-forward refs to a
new function in remote.[ch], set_ref_status_for_push().
Make transport_push() invoke set_ref_status_for_push() before invoking
the push_refs() implementation. (As a side-effect, the push_refs()
implementation in transport-helper.c now knows of non-fast-forward
pushes.)
Removed logic for detecting up-to-date refs from the push_refs()
implementation in transport-helper.c, as transport_push() has already
done so for it.
Make cmd_send_pack() invoke set_ref_status_for_push() before invoking
send_pack(), as transport_push() can't do it for send_pack() here.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
In v1, this was spread over two patches. I squashed them into one
(here).
set_ref_status_for_push() used to be called inside the for loop over
remote_refs; now, it has its own for loop.
builtin-send-pack.c | 50 +++++++++++---------------------------------------
remote.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
remote.h | 2 ++
transport-helper.c | 13 ++++++-------
transport.c | 4 ++++
5 files changed, 73 insertions(+), 46 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 8fffdbf..38580c3 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -406,50 +406,19 @@ int send_pack(struct send_pack_args *args,
*/
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
-
- if (ref->peer_ref)
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
- else if (!args->send_mirror)
+ if (!ref->peer_ref && !args->send_mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (ref->deletion && !allow_deleting_refs) {
- ref->status = REF_STATUS_REJECT_NODELETE;
- continue;
- }
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
+ switch (ref->status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_UPTODATE:
continue;
+ default:
+ ; /* do nothing */
}
- /* This part determines what can overwrite what.
- * The rules are:
- *
- * (0) you can always use --force or +A:B notation to
- * selectively force individual ref pairs.
- *
- * (1) if the old thing does not exist, it is OK.
- *
- * (2) if you do not have the old thing, you are not allowed
- * to overwrite it; you would not know what you are losing
- * otherwise.
- *
- * (3) if both new and old are commit-ish, and new is a
- * descendant of old, it is OK.
- *
- * (4) regardless of all of the above, removing :B is
- * always allowed.
- */
-
- ref->nonfastforward =
- !ref->deletion &&
- !is_null_sha1(ref->old_sha1) &&
- (!has_sha1_file(ref->old_sha1)
- || !ref_newer(ref->new_sha1, ref->old_sha1));
-
- if (ref->nonfastforward && !ref->force && !args->force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ if (ref->deletion && !allow_deleting_refs) {
+ ref->status = REF_STATUS_REJECT_NODELETE;
continue;
}
@@ -673,6 +642,9 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
if (match_refs(local_refs, &remote_refs, nr_refspecs, refspecs, flags))
return -1;
+ set_ref_status_for_push(remote_refs, args.send_mirror,
+ args.force_update);
+
ret = send_pack(&args, fd, conn, remote_refs, &extra_have);
if (helper_status)
diff --git a/remote.c b/remote.c
index e3afecd..c70181c 100644
--- a/remote.c
+++ b/remote.c
@@ -1247,6 +1247,56 @@ int match_refs(struct ref *src, struct ref **dst,
return 0;
}
+void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
+ int force_update)
+{
+ struct ref *ref;
+
+ for (ref = remote_refs; ref; ref = ref->next) {
+ if (ref->peer_ref)
+ hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
+ else if (!send_mirror)
+ continue;
+
+ ref->deletion = is_null_sha1(ref->new_sha1);
+ if (!ref->deletion &&
+ !hashcmp(ref->old_sha1, ref->new_sha1)) {
+ ref->status = REF_STATUS_UPTODATE;
+ continue;
+ }
+
+ /* This part determines what can overwrite what.
+ * The rules are:
+ *
+ * (0) you can always use --force or +A:B notation to
+ * selectively force individual ref pairs.
+ *
+ * (1) if the old thing does not exist, it is OK.
+ *
+ * (2) if you do not have the old thing, you are not allowed
+ * to overwrite it; you would not know what you are losing
+ * otherwise.
+ *
+ * (3) if both new and old are commit-ish, and new is a
+ * descendant of old, it is OK.
+ *
+ * (4) regardless of all of the above, removing :B is
+ * always allowed.
+ */
+
+ ref->nonfastforward =
+ !ref->deletion &&
+ !is_null_sha1(ref->old_sha1) &&
+ (!has_sha1_file(ref->old_sha1)
+ || !ref_newer(ref->new_sha1, ref->old_sha1));
+
+ if (ref->nonfastforward && !ref->force && !force_update) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
+ }
+}
+
struct branch *branch_get(const char *name)
{
struct branch *ret;
diff --git a/remote.h b/remote.h
index 8b7ecf9..6e13643 100644
--- a/remote.h
+++ b/remote.h
@@ -98,6 +98,8 @@ char *apply_refspecs(struct refspec *refspecs, int nr_refspec,
int match_refs(struct ref *src, struct ref **dst,
int nr_refspec, const char **refspec, int all);
+void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
+ int force_update);
/*
* Given a list of the remote refs and the specification of things to
diff --git a/transport-helper.c b/transport-helper.c
index 11f3d7e..6b1f778 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -329,16 +329,15 @@ static int push_refs(struct transport *transport,
return 1;
for (ref = remote_refs; ref; ref = ref->next) {
- if (ref->peer_ref)
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
- else if (!mirror)
+ if (!ref->peer_ref && !mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
+ switch (ref->status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_UPTODATE:
continue;
+ default:
+ ; /* do nothing */
}
if (force_all)
diff --git a/transport.c b/transport.c
index 3eea836..12c4423 100644
--- a/transport.c
+++ b/transport.c
@@ -887,6 +887,10 @@ int transport_push(struct transport *transport,
return -1;
}
+ set_ref_status_for_push(remote_refs,
+ flags & TRANSPORT_PUSH_MIRROR,
+ flags & TRANSPORT_PUSH_FORCE);
+
ret = transport->push_refs(transport, remote_refs, flags);
if (!quiet || push_had_errors(remote_refs))
--
1.6.4.4
^ permalink raw reply related
* [PATCH v2 0/3] transport: catch non-fast-forwards
From: Tay Ray Chuan @ 2009-12-08 14:34 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091204125042.c64f347d.rctay89@gmail.com>
Daniel, I've reworked the refactoring of ref status logic, like you
mentioned, such that transport_push() calls the generic function before
calling the transport->push_refs() implementation.
Junio, although this series affects http transports (smart), please treat
this series as separate from 'tr/http-updates' in 'next'.
Summary for those who missed v1:
This patch series applies on top of 'next', and deals with alerting
the user to non-fast-forward pushes when using helpers (smart).
Previously, git silently exited. This situation involves the curl
helper and the smart protocol. The fast-forward push is only detected
when curl executes the rpc client (git-send-pack). Now, we detect it
before telling the helper to push.
Changes from v1:
- reworked refactoring of ref status logic (patch 1)
- rewrote the patch for transport_push() (patch 2)
- minor rewording of commit message (patch 3)
Tay Ray Chuan (3):
refactor ref status logic for pushing
transport.c::transport_push(): make ref status affect return value
transport-helper.c::push_refs(): emit "no refs" error message
builtin-send-pack.c | 50 +++++++++++---------------------------------------
remote.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
remote.h | 2 ++
transport-helper.c | 18 ++++++++++--------
transport.c | 11 +++++++++--
5 files changed, 82 insertions(+), 49 deletions(-)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Erik Faye-Lund @ 2009-12-08 14:23 UTC (permalink / raw)
To: Ferry Huberts; +Cc: Yann Dirson, GIT ml
In-Reply-To: <4B1E57BF.1000500@pelagic.nl>
On Tue, Dec 8, 2009 at 2:42 PM, Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
> On 12/08/2009 02:34 PM, Erik Faye-Lund wrote:
>> On Tue, Dec 8, 2009 at 2:28 PM, Yann Dirson <ydirson@linagora.com> wrote:
>>> I'm not sure who's at fault here - namely, I can't see any valid
>>> reason for eclipse to refuse such writes, but I am not sure it is a
>>> good reason for msysgit would set the hidden bit either. In either
>>> case, even if only for the short term, I think msysgit should ensure
>>> that this bit does not get set (possibly circumventing any magic msys
>>> would do behind its back).
>>
>> Setting the config option "core.hidedotfiles" to "false" should
>> prevent this from happening.
>>
>
> why isn't this the default?
>
> I also experienced this change in behaviour and I thought we would
> strive to keep the experience the same.
>
You can follow the discussion here:
http://code.google.com/p/msysgit/issues/detail?id=288
I believe the reason is something like "because someone suggested it,
and no one disagreed". Do you have a good argument why it shouldn't be
the default (other than "it's a change", because changing it back now
would also be a change)?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Add commit.status, --status, and --no-status
From: James P. Howard, II @ 2009-12-08 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vr5r6ndkz.fsf@alter.siamese.dyndns.org>
On Tue, Dec 8, 2009 at 02:13, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Mon, Dec 07, 2009 at 05:45:27PM -0500, James P. Howard, II wrote:
>>
>>> This commit provides support for commit.status, --status, and
>>> --no-status, which control whether or not the git status information
>>> is included in the commit message template when using an editor to
>>> prepare the commit message. It does not affect the effects of a
>>> user's commit.template settings.
>>
>> Thanks, this looks very cleanly done. The only complaint I would make is
>> that it should probably include a simple test case.
>
> Yes. Also I am a _bit_ worried about the name "status", as the longer
> term direction is to make "status" not "a preview of commit", may confuse
> people who do read Release Notes.
Right now, this option does not affect how the commit message is prepared
in git tag. If the option were extended to cover that case as well, what would
a sensible name for the option be, then?
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 03/11] mingw: implement syslog
From: Erik Faye-Lund @ 2009-12-08 14:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911272023.58262.j6t@kdbg.org>
On Fri, Nov 27, 2009 at 8:23 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 27. November 2009, Erik Faye-Lund wrote:
>> On Thu, Nov 26, 2009 at 10:23 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> > I would
>> >
>> > const char* arg;
>> > if (strcmp(fmt, "%s"))
>> > die("format string of syslog() not implemented")
>> > va_start(va, fmt);
>> > arg = va_arg(va, char*);
>> > va_end(va);
>> >
>> > because we have exactly one invocation of syslog(), which passes "%s" as
>> > format string. Then strbuf_vaddf is not needed. Or even simpler: declare
>> > the function as
>> >
>> > void syslog(int priority, const char *fmt, const char*arg);
>>
>> After reading this again, I agree that this is the best solution. I'll
>> update for the next iteration.
>
> Except that you shouldn't die like I proposed because here we are already in
> the die_routine, no?
>
Might be. Either way, I think loosing a log-entry is better than
taking down the server. I'm just doing a warning() and return. If
we're lucky, the warning gets somewhere. If not, well, something
happened and no one was around to see it.
>> > "Note that the string that you log cannot contain %n, where n is an
>> > integer value (for example, %1) because the event viewer treats it as an
>> > insertion string. ..."
>> >
>> > How are the chances that this condition applies to our use of the
>> > function?
>>
>> Ugh, increasingly high since we're adding IPv6 support, I guess.
>> Perhaps some form of escaping needs to be done?
>
> I think so, but actually I have no clue.
>
Bah, according to Microsoft Support (1), there's no simple way to
escape this. I'm tempted to leave this bug in, and rather try to fix
the symptoms when/if they start popping up. Unless someone else comes
up with something better, that is.
(1) http://support.microsoft.com/kb/934640
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Ferry Huberts @ 2009-12-08 13:42 UTC (permalink / raw)
To: kusmabite; +Cc: Yann Dirson, GIT ml
In-Reply-To: <40aa078e0912080534x32fe9724xcda47ad46dbdb7c0@mail.gmail.com>
On 12/08/2009 02:34 PM, Erik Faye-Lund wrote:
> On Tue, Dec 8, 2009 at 2:28 PM, Yann Dirson <ydirson@linagora.com> wrote:
>> I'm not sure who's at fault here - namely, I can't see any valid
>> reason for eclipse to refuse such writes, but I am not sure it is a
>> good reason for msysgit would set the hidden bit either. In either
>> case, even if only for the short term, I think msysgit should ensure
>> that this bit does not get set (possibly circumventing any magic msys
>> would do behind its back).
>
> Setting the config option "core.hidedotfiles" to "false" should
> prevent this from happening.
>
why isn't this the default?
I also experienced this change in behaviour and I thought we would
strive to keep the experience the same.
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Sverre Rabbelier @ 2009-12-08 13:51 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin,
Matthieu Moy, Michael J Gruber, Michael Haggerty, git
In-Reply-To: <20091208093515.GA32655@sigill.intra.peff.net>
Heya,
On Tue, Dec 8, 2009 at 10:35, Jeff King <peff@peff.net> wrote:
> $ bash
> $ echo "!fixup commit"
> bash: !fixup: event not found
> $ echo "fixup! commit"
> fixup! commit
Speaking of which, must we use that annoying bang? I hate how bash
gets in my way when I try to write a commit message with a a bang in
it, I'd much rather use a different character that is not in risk of
being mistreated by my shell. (Although it seems that bash does do TRT
in the 'fixup!' case.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/RFC 07/11] run-command: support input-fd
From: Erik Faye-Lund @ 2009-12-08 13:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911272114.13107.j6t@kdbg.org>
On Fri, Nov 27, 2009 at 9:14 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 27. November 2009, Erik Faye-Lund wrote:
>> What do you find confusing about it? The idea is to use a provided
>> bi-directional fd instead of a pipe if async->out is non-zero. The
>> currently defined rules for async is that async->out must be zero
>> (since the structure should be zero-initialized).
>
> It is just the code structure that is confusing. It should be
>
> if (async->out) {
> /* fd was provided */
> do all that is needed in this case
> } else {
> /* fd was requested */
> do all for this other case
> }
> /* nothing to do anymore here */
>
> (Of course, this should only replace the part that is cited above, not the
> whole function.)
>
OK. I've reimplemented the change for the next round, taking this into account.
>> Indeed it does. Do we want to extend it to support a set of
>> unidirectional channels instead?
>
> Yes, I think so. We could pass a regular int fd[2] array around with the clear
> definition that both can be closed independently, i.e. one must be a dup() of
> the other. struct async would also have such an array.
>
OK. This has been included for the next round. Instead of an array,
I've tried to be consistent with start_command, and used two
variables, "in" and "out".
> Speaking of dup(): The underlying function is DuplicateHandle(), and its
> documentation says:
>
> "You should not use DuplicateHandle to duplicate handles to the following
> objects: ... o Sockets. ... use WSADuplicateSocket."
>
> But then the docs of WSADuplicateSocket() talk only about duplicating a socket
> to a separate process. Perhaps DuplicateHandle() of a socket within the same
> process Just Works?
>
It seems the rest of the Windows-world depends on DuplicateHandle()
working for sockets, so I'm not too worried. I can't find anything
documentation(1) for _dup, and I don't think we have our own
dup()-implementation.
(1) http://msdn.microsoft.com/en-us/library/8syseb29(VS.71).aspx
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: help: bisect single file from repos
From: walter harms @ 2009-12-08 13:41 UTC (permalink / raw)
To: Christian Couder; +Cc: Michael J Gruber, git
In-Reply-To: <200912080917.17220.chriscool@tuxfamily.org>
Christian Couder schrieb:
> Hi,
>
> On lundi 07 décembre 2009, walter harms wrote:
>> Michael J Gruber schrieb:
>>> walter harms venit, vidit, dixit 07.12.2009 13:59:
>>>> Hi list,
>>>> i am new to git (using: git version 1.6.0.2).
>>> though your git is not that new ;)
>>>
>>>> I would like to bisect a single file but i have only commit id, no
>>>> tags.
>>>>
>>>> Background:
>>>> I have a copy of the busybox git repos, and i know there is (perhaps)
>>>> a bug in ash.c.
>>>>
>>>> how can i do that ?
>>> You don't need any tags for bisecting. The man page of git-bisect has
>>> several examples on how to use it. Do you have a test script which
>>> exposes the bug?
>> unfortunately no, the error shows up very nicely when booting my
>> embdedded system but not else (this is the reason i would to bisect that
>> file only and not busybox completely). And from the man pages i got the
>> impression that it is only possible the start with a tag.
>
> The man page says:
>
> git bisect start [<bad> [<good>...]] [--] [<paths>...]
>
> and then:
>
> "This command uses git rev-list --bisect to help drive the binary search
> process to find which change introduced a bug, given an old "good" commit
> object name and a later "bad" commit object name."
i am sorry, i am not familiar with git and when i am stating i am looking
for examples first. the examples in my man page are like
git bisect start v2.6.20-rc6 v2.6.20-rc4
there is nothing like:
git bisect start 6a87a68a6a8 65a76a8a68a7
I ASSUME that you can use tags like "v2.6.20-rc6" and commit-id like "6a87a68a6a8"
interchangeable but that was not clear from beginning.
BTW did you notice the sentence says "commit object name" not "commit id" ? when
you are starting you are not familiar with the wording so you do not make the connection.
>> i already had the hint that i need to do:
>> git bisect start bad_commit_id good_commit_id -- ash.c
>
> So did you try that?
>
not yet, we are still using an older version of BB for production. So there is no hurry.
The problem is that we can not found the reason for the bug. NTL i plan for this week.
>> Ntl, there is one more question, how can i make sure that
>> i use the right version ?
>
> If you mean the right git version, then I think any 1.6.X should be enough.
>
>> first i toughed that cherry-pick is the right
>> idea but it seems that that will apply onyl certain patches ?
>
> If you want to find the commit that introduced a bug, then you should not
> need cherry-pick.
>
mmh, no, the idea was to use something like
git "checkou" <id> and having a version that represents THAT moment.
re,
wh
> Regards,
> Christian.
>
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 08/11] daemon: use explicit file descriptor
From: Erik Faye-Lund @ 2009-12-08 13:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911272128.48974.j6t@kdbg.org>
On Fri, Nov 27, 2009 at 9:28 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 27. November 2009, Johannes Sixt wrote:
>> On Freitag, 27. November 2009, Erik Faye-Lund wrote:
>> > When I think more about it, I might've broken the inetd-mode as it
>> > should communicate over stdin and stdout (not just stdin as it would
>> > try to do now)... I don't know the inetd internals, but this frightens
>> > me a bit.
>>
>> Do we need inetd mode on Windows? At one time a looked for a inetd-like
>> service, but couldn't find one.
>
> How foolish of me. This affects all platforms. Of course it is an important to
> keep inetd mode.
>
> -- Hannes
>
I believe I've fixed this for the next round, but I haven't been able
to test the inetd-stuff, since I don't have a working
test-environment.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH/RFC 09/11] daemon: use run-command api for async serving
From: Erik Faye-Lund @ 2009-12-08 13:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200912022012.08905.j6t@kdbg.org>
On Wed, Dec 2, 2009 at 8:12 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Mittwoch, 2. Dezember 2009, Erik Faye-Lund wrote:
>> I'm not entirely sure how to make the interface, though. Any good
>> suggestions?
>
> I suggest to model finish_async_nowait() after waitpid() so that
>
> while ((pid = waitpid(-1, &status, WNOHANG)) > 0) ...
> becomes
> while ((pid = finish_async_nowait(&some_async, &status)) > 0) ...
>
> but where the resulting status is already "decoded", i.e. zero is success and
> non-zero is failure (including death through signal); WIFEXITED and
> WEXITSTATUS should not be applicable to status anymore.
>
> -- Hannes
>
Thanks. Implemented as suggested for the next round.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Erik Faye-Lund @ 2009-12-08 13:34 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT ml
In-Reply-To: <20091208132857.GB5425@linagora.com>
On Tue, Dec 8, 2009 at 2:28 PM, Yann Dirson <ydirson@linagora.com> wrote:
> I'm not sure who's at fault here - namely, I can't see any valid
> reason for eclipse to refuse such writes, but I am not sure it is a
> good reason for msysgit would set the hidden bit either. In either
> case, even if only for the short term, I think msysgit should ensure
> that this bit does not get set (possibly circumventing any magic msys
> would do behind its back).
Setting the config option "core.hidedotfiles" to "false" should
prevent this from happening.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [BUG] Bad msysgit/egit interaction over dotfiles
From: Yann Dirson @ 2009-12-08 13:28 UTC (permalink / raw)
To: GIT ml
Some devs here started to use egit on windows, and since egit is not
complete yet, occasionally^Wregularly use msysgit for
rebase/stash/you-name-it.
This revealed a strange problem that took some time figuring out,
where eclipse refused to write to .classpath or .project, just saying
"could not write", while other apps had no problem editing the same
files.
In the end, the problem is that the dotfiles had the "hidden" bit set,
and that for some reason eclipse does not allow to write to hidden
files - and that the one (re)setting the "hidden" bit over and over
again is msysgit, whenever it checkouts such a dotfile - surely to
emulate the unix behaviour of hiding dotfiles by default.
I'm not sure who's at fault here - namely, I can't see any valid
reason for eclipse to refuse such writes, but I am not sure it is a
good reason for msysgit would set the hidden bit either. In either
case, even if only for the short term, I think msysgit should ensure
that this bit does not get set (possibly circumventing any magic msys
would do behind its back).
Best regards,
--
Yann
^ permalink raw reply
* [REROLL PATCH 8/8] Remove special casing of http, https and ftp
From: Ilari Liusvaara @ 2009-12-08 13:16 UTC (permalink / raw)
To: git
In-Reply-To: <1260278177-9029-1-git-send-email-ilari.liusvaara@elisanet.fi>
HTTP, HTTPS and FTP are no longer special to transport code. Also
add support for FTPS (curl supports it so it is easy).
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
.gitignore | 4 ++++
Makefile | 24 ++++++++++++++++++++++--
transport.c | 8 --------
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/.gitignore b/.gitignore
index ac02a58..aa7a8ac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -107,6 +107,10 @@
/git-relink
/git-remote
/git-remote-curl
+/git-remote-http
+/git-remote-https
+/git-remote-ftp
+/git-remote-ftps
/git-repack
/git-replace
/git-repo-config
diff --git a/Makefile b/Makefile
index 2ad7e36..546a408 100644
--- a/Makefile
+++ b/Makefile
@@ -424,6 +424,13 @@ BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
+#ifdef NO_CURL
+REMOTE_CURL_NAMES =
+#else
+# Yes, this is missing git-remote-http intentionally!
+REMOTE_CURL_NAMES = git-remote-https git-remote-ftp git-remote-ftps
+#endif
+
# what 'all' will build and 'install' will install in gitexecdir,
# excluding programs for built-in commands
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
@@ -1097,7 +1104,7 @@ else
else
CURL_LIBCURL = -lcurl
endif
- PROGRAMS += git-remote-curl$X git-http-fetch$X
+ PROGRAMS += git-remote-http$X git-remote-https$X git-remote-ftp$X git-remote-ftps$X git-http-fetch$X
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
@@ -1676,7 +1683,13 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
+$(REMOTE_CURL_NAMES): git-remote-http$X
+ $(QUIET_LNCP)$(RM) $@ && \
+ ln $< $@ 2>/dev/null || \
+ ln -s $< $@ 2>/dev/null || \
+ cp $< $@
+
+git-remote-http$X: remote-curl.o http.o http-walker.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
@@ -1852,6 +1865,7 @@ endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), test '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' -ef '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p$X' || $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
+
bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
{ test "$$bindir/" = "$$execdir/" || \
@@ -1865,6 +1879,12 @@ endif
ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
cp "$$execdir/git$X" "$$execdir/$$p" || exit; \
done; } && \
+ { for p in $(REMOTE_CURL_NAMES); do \
+ $(RM) "$$execdir/$$p" && \
+ ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
+ done; } && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
diff --git a/transport.c b/transport.c
index 64938fd..211114e 100644
--- a/transport.c
+++ b/transport.c
@@ -932,14 +932,6 @@ struct transport *transport_get(struct remote *remote, const char *url)
data->conn = NULL;
data->got_remote_heads = 0;
- } else if (!prefixcmp(url, "http://")
- || !prefixcmp(url, "https://")
- || !prefixcmp(url, "ftp://")) {
- /* These three are just plain special. */
- transport_helper_init(ret, "curl");
-#ifdef NO_CURL
- error("git was compiled without libcurl support.");
-#endif
} else {
/* Unknown protocol in URL. Pass to external handler. */
int len = external_specification_len(url);
--
1.6.6.rc1.300.gfbc27
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox