* [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
* [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 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
* 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 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: [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 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
* [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
* 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
* 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
* [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
* [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
* 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
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 16:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208144740.GA30830@redhat.com>
On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> 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?
This pretty much reverses what rebase normally does. Instead of "rebase
this onto that" it's "'rebase' that onto this". And instead of updating
the branch head that got rebased, the, uhm, "upstream" gets updated.
Also, AFAICT this needs to be called like this:
git rebase --revisions foo..bar HEAD
Changing the meaning of the <upstream> argument and relying on the fact
that <newbase> defaults to <upstream>. If such a thing gets added, it
should rather work like --root, not using <upstream> at all, but --onto
<newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
optional, as it's reversed WRT what it does compared to the usual
rebase.
But generally, I'd say it would be better to add such a range feature to
cherry-pick than abusing rebase for that.
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:11 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208160822.GA1299@atjola.homenet>
On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > 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?
>
> This pretty much reverses what rebase normally does. Instead of "rebase
> this onto that" it's "'rebase' that onto this". And instead of updating
> the branch head that got rebased, the, uhm, "upstream" gets updated.
>
> Also, AFAICT this needs to be called like this:
> git rebase --revisions foo..bar HEAD
>
> Changing the meaning of the <upstream> argument and relying on the fact
> that <newbase> defaults to <upstream>. If such a thing gets added, it
> should rather work like --root, not using <upstream> at all, but --onto
> <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> optional, as it's reversed WRT what it does compared to the usual
> rebase.
Sorry, I had trouble parsing the above. Could you suggest e.g. how the
help line should look?
> But generally, I'd say it would be better to add such a range feature to
> cherry-pick than abusing rebase for that.
>
> Björn
The reason to use rebase is that I often want to combine
this with -i flag, editing patches as they are applied.
--
MST
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:14 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208160822.GA1299@atjola.homenet>
On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > 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?
>
> This pretty much reverses what rebase normally does. Instead of "rebase
> this onto that" it's "'rebase' that onto this". And instead of updating
> the branch head that got rebased, the, uhm, "upstream" gets updated.
The last sentence is wrong I think - it is still the branch head that
is updated.
^ permalink raw reply
* PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Jakub Narebski @ 2009-12-08 16:29 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1260148741.1579.50.camel@swboyd-laptop>
On Mon, 7 Dec 2009, Stephen Boyd wrote:
> On Sun, 2009-12-06 at 17:04 -0800, Stephen Boyd wrote:
> >
> > Ok. It's December and I've had some more time to look into this.
> > Initializing 'xhr' to null seems to get rid of the "Unknown error"
> > problem (see patch below).
> >
>
> Ah sorry. Seems this doesn't work and I was just getting lucky.
Does the following fixes the issue for IE8 for you (it works for me)?
As for testing, try with blaming 'revision.c' and 'gitweb/gitweb.perl'
using 'blame_incremental' view.
With probably too long commit message, and not detailed enough title:
-- >8 --
Subject: [PATCH] gitweb.js: Workaround for IE8 bug
In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.
The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:
if (xhr.readyState === 3 && xhr.status !== 200) {
Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.
This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases. It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server. It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).
Work around this bug in IE8 by using try-catch block when accessing
xhr.status.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.js | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 2a25b7c..9c66928 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -779,7 +779,12 @@ function handleResponse() {
}
// the server returned error
- if (xhr.readyState === 3 && xhr.status !== 200) {
+ // try ... catch block is to work around bug in IE8
+ try {
+ if (xhr.readyState === 3 && xhr.status !== 200) {
+ return;
+ }
+ } catch (e) {
return;
}
if (xhr.readyState === 4 && xhr.status !== 200) {
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 16:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208161142.GA32045@redhat.com>
On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > 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?
> >
> > This pretty much reverses what rebase normally does. Instead of "rebase
> > this onto that" it's "'rebase' that onto this". And instead of updating
> > the branch head that got rebased, the, uhm, "upstream" gets updated.
> >
> > Also, AFAICT this needs to be called like this:
> > git rebase --revisions foo..bar HEAD
> >
> > Changing the meaning of the <upstream> argument and relying on the fact
> > that <newbase> defaults to <upstream>. If such a thing gets added, it
> > should rather work like --root, not using <upstream> at all, but --onto
> > <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> > optional, as it's reversed WRT what it does compared to the usual
> > rebase.
>
> Sorry, I had trouble parsing the above. Could you suggest e.g. how the
> help line should look?
Current:
git rebase [-i | --interactive] [options] [--onto <newbase>]
<upstream> [<branch>]
git rebase [-i | --interactive] [options] --onto <newbase>
--root [<branch>]
Add:
git rebase [-i | --interactive] [options] --revisions <range> [<branch>]
(Thinking about it, I guess an explicit --onto makes no sense with the
--revisions flag)
> > But generally, I'd say it would be better to add such a range feature to
> > cherry-pick than abusing rebase for that.
>
> The reason to use rebase is that I often want to combine
> this with -i flag, editing patches as they are applied.
Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:44 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208163737.GA2005@atjola.homenet>
On Tue, Dec 08, 2009 at 05:37:37PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > > 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?
> > >
> > > This pretty much reverses what rebase normally does. Instead of "rebase
> > > this onto that" it's "'rebase' that onto this". And instead of updating
> > > the branch head that got rebased, the, uhm, "upstream" gets updated.
> >
> > The last sentence is wrong I think - it is still the branch head that
> > is updated.
>
> But you don't rebase the branch head. Before the rebase, the branch head
> doesn't reference the commits that get rebased. For example:
>
> git checkout bar
> git rebase --revisions foo bar
>
> You "rebase" the commits in foo's history, but you update bar.
Yes, that's the who point of the patch. The above applies a single
commit, foo, on top of current branch bar.
> WRT the result, the above command should be equivalent to:
> git checkout bar
> git reset --hard foo
> git rebase --root --onto ORIG_HEAD;
>
> And here, the commits currently reachable through "bar" are rebased, and
> "bar" also gets updated.
>
> Björn
So this
1. won't be very useful, as you show it is easy
to achieve with existing commands.
2. interprets "foo" as branch name as opposed to
revision range.
OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which
can't easily be achieved with existing commands, especially if you add
"-i".
--
MST
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:49 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208164113.GB2005@atjola.homenet>
On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > > 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?
> > >
> > > This pretty much reverses what rebase normally does. Instead of "rebase
> > > this onto that" it's "'rebase' that onto this". And instead of updating
> > > the branch head that got rebased, the, uhm, "upstream" gets updated.
> > >
> > > Also, AFAICT this needs to be called like this:
> > > git rebase --revisions foo..bar HEAD
> > >
> > > Changing the meaning of the <upstream> argument and relying on the fact
> > > that <newbase> defaults to <upstream>. If such a thing gets added, it
> > > should rather work like --root, not using <upstream> at all, but --onto
> > > <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> > > optional, as it's reversed WRT what it does compared to the usual
> > > rebase.
> >
> > Sorry, I had trouble parsing the above. Could you suggest e.g. how the
> > help line should look?
>
> Current:
> git rebase [-i | --interactive] [options] [--onto <newbase>]
> <upstream> [<branch>]
> git rebase [-i | --interactive] [options] --onto <newbase>
> --root [<branch>]
>
> Add:
> git rebase [-i | --interactive] [options] --revisions <range> [<branch>]
>
> (Thinking about it, I guess an explicit --onto makes no sense with the
> --revisions flag)
I agree.
So this is different from what I implemented basically only in that
we should disallow combining --onto with --revisions. Right?
> > > But generally, I'd say it would be better to add such a range feature to
> > > cherry-pick than abusing rebase for that.
> >
> > The reason to use rebase is that I often want to combine
> > this with -i flag, editing patches as they are applied.
>
> Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)
>
> Björn
Ah, I was wondering why it doesn't work :)
^ permalink raw reply
* Re: [PATCH v2 1/3] refactor ref status logic for pushing
From: Daniel Barkalow @ 2009-12-08 17:17 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Clemens Buchacher,
Jeff King, Junio C Hamano
In-Reply-To: <20091208223543.c7f88afe.rctay89@gmail.com>
On Tue, 8 Dec 2009, Tay Ray Chuan wrote:
> 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().
Is there some reason to not have set_ref_status_for_push() be static in
transport.c now? (Sorry for not suggesting this before.)
Other than that, it looks good to me.
I think it might be a good idea to have it generate a peer ref for refs
that don't have one when mirror is used, which would eliminate a couple
more lines, but there's no reason that has to be done in the same patch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Undoing merges
From: rhlee @ 2009-12-08 17:34 UTC (permalink / raw)
To: git
Hi git list,
I hope this isn't a double post. I couldn't get a response from this mailing
list with Outlook.
I'm trying to find out how to undo a merge. I know that my branches are
independent and that I can just carry on working on them and merge again
later, but I'm just trying to keep my revision graph tidier. Should I even
be undoing merges?
I've searched around, but I can seem to find an answer I can follow.
Regards,
Richard
--
View this message in context: http://n2.nabble.com/Undoing-merges-tp4133942p4133942.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 16:37 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208161406.GB32045@redhat.com>
On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > 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?
> >
> > This pretty much reverses what rebase normally does. Instead of "rebase
> > this onto that" it's "'rebase' that onto this". And instead of updating
> > the branch head that got rebased, the, uhm, "upstream" gets updated.
>
> The last sentence is wrong I think - it is still the branch head that
> is updated.
But you don't rebase the branch head. Before the rebase, the branch head
doesn't reference the commits that get rebased. For example:
git checkout bar
git rebase --revisions foo bar
You "rebase" the commits in foo's history, but you update bar.
WRT the result, the above command should be equivalent to:
git checkout bar
git reset --hard foo
git rebase --root --onto ORIG_HEAD;
And here, the commits currently reachable through "bar" are rebased, and
"bar" also gets updated.
Björn
^ permalink raw reply
* Undoing merges
From: Richard @ 2009-12-08 17:16 UTC (permalink / raw)
To: git
Hi git list,
I'm trying to find out how to undo a merge. I know that my branches are
independent and that I can just carry on working on them and merge again
later, but I'm just trying to keep my revision graph tidier. Should I
even be undoing merges?
I've searched around, but I can seem to find an answer I can follow.
Regards,
Richard
^ permalink raw reply
* Re: Undoing merges
From: Matthieu Moy @ 2009-12-08 17:48 UTC (permalink / raw)
To: Richard; +Cc: git
In-Reply-To: <8440EA2C12E50645A68C4AA98871665131D8D8@SERVER.webdezign.local>
"Richard" <richard@webdezign.co.uk> writes:
> Hi git list,
>
> I'm trying to find out how to undo a merge.
When sitting on a merge commit,
git reset --merge HEAD^
will undo this merge commit (i.e. pretend the merge has never occured,
at least in your branch). Don't do that if you already published this
merge commit.
> I know that my branches are independent and that I can just carry on
> working on them and merge again later, but I'm just trying to keep
> my revision graph tidier. Should I even be undoing merges?
If it's about cleaning up your history, "git rebase" is your friend,
too (with the same limitation: don't do that on published history). By
default, it does some kind of history flattening.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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