* Re: [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Junio C Hamano @ 2007-09-01 6:16 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <46D8F431.70801@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> if (pattern == NULL)
> - pattern = "";
> + pattern = "*";
>
> - /* prepend/append * to the shell pattern: */
> - newpattern = xmalloc(strlen(pattern) + 3);
> - sprintf(newpattern, "*%s*", pattern);
> -
> - filter.pattern = newpattern;
> + filter.pattern = pattern;
> filter.lines = lines;
>
> for_each_tag_ref(show_reference, (void *) &filter);
I think it is conceptually simpler on the show_reference side to
allow (filter.pattern == NULL) and say:
if (!filter->pattern || !fnmatch(filter->pattern, refname, 0)) {
... show that ref ...
}
It is not such a big deal now you do not do newpattern
allocation anymore, so I'll apply the patch as is.
^ permalink raw reply
* [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.
From: Johannes Sixt @ 2007-09-01 7:25 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:
o--X--A--B--Y <- master
\
A--B--Z <- topic
then 'git rebase -m master' would report:
Already applied: 0001 Y
Already applied: 0002 Y
With this fix it reports the expected:
Already applied: 0001 A
Already applied: 0002 B
As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-rebase.sh | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index cbafa14..9cf0056 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -59,20 +59,23 @@ continue_merge () {
die "$RESOLVEMSG"
fi
+ cmt=`cat $dotest/current`
if ! git diff-index --quiet HEAD
then
- if ! git-commit -C "`cat $dotest/current`"
+ if ! git-commit -C "$cmt"
then
echo "Commit failed, please do not call \"git commit\""
echo "directly, but instead do one of the following: "
die "$RESOLVEMSG"
fi
- printf "Committed: %0${prec}d" $msgnum
+ printf "Committed: %0${prec}d " $msgnum
+ git rev-list --pretty=oneline -1 HEAD | \
+ sed 's/^[a-f0-9]\+ //'
else
- printf "Already applied: %0${prec}d" $msgnum
+ printf "Already applied: %0${prec}d " $msgnum
+ git rev-list --pretty=oneline -1 "$cmt" | \
+ sed 's/^[a-f0-9]\+ //'
fi
- echo ' '`git rev-list --pretty=oneline -1 HEAD | \
- sed 's/^[a-f0-9]\+ //'`
prev_head=`git rev-parse HEAD^0`
# save the resulting commit so we can read-tree on it later
--
1.5.3.rc6.55.ga005
^ permalink raw reply related
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Jari Aalto @ 2007-09-01 8:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7frzfzg.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>> The manual mixed both caret(HEAD^) and tilde (HEAD~N) notation in
>> examples. This may be xconfusing to new users. The "counting" notation
>> HEAD~N likely to be grasped more easily because it allow successive
>> numbering 1, 2, 3 etc.
>
> I am mildly negative on this change.
>
> Referring to (rather, "having to refer to" to fix mistakes) the
> previous commit happens far more often than referring to an
> ancestor of an arbitrary generation away (i.e. HEAD~$n). I
> think it is a better idea to expose users early on that HEAD^
> notation which is shorter to type.
If the page contains/combines many different ways of doing things,
this creates confusion, especially if the distictions are not explained.
And it would be unnecessary to explain the HEAD^ and HEAD~1 similarities
in every page where these two get mixed.
PRICPLES:
1. The novice user is best served by making things simple and uniform.
2. Utilize concepts that may already be familar. E.g. other VCS/SCM tools
have concept of counting back revisions with negative numbers: -1,
-2, -3; so following this same idea in git manual pages would
already rang associated bells.
Like:
HEAD, HEAD~1, HEAD~2
If the syntax is changed in the middle (as it was in manual page),
that interrupts the kognitive flow of reading.
HEAD, HEAD^, HEAD~2
I'm sure when user progresses with his learning, the differences or
similarities of the notations become no-op.
But manual pages are served for wide audience. They are most
important to new users.
I hope we could strive for KISS is possible.
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.
From: Junio C Hamano @ 2007-09-01 9:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200709010925.27926.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> When a topic branch is rebased, some of whose commits are already
> cherry-picked upstream:
>
> o--X--A--B--Y <- master
> \
> A--B--Z <- topic
>
> then 'git rebase -m master' would report:
>
> Already applied: 0001 Y
> Already applied: 0002 Y
>
> With this fix it reports the expected:
>
> Already applied: 0001 A
> Already applied: 0002 B
Well, good eyes. A new test script would have been nice.
> + printf "Already applied: %0${prec}d " $msgnum
> + git rev-list --pretty=oneline -1 "$cmt" | \
> + sed 's/^[a-f0-9]\+ //'
This is not your fault but I just noticed this sed script that
steps outside BRE [*1*, *2*]. In this case we do not even need
to use '\+', as we know what we are reading.
A few "sed" disciplines to keep things portable I tried to
follow so far are:
- Always use '-e' to introduce expression;
- Don't use two expressions concatenated with ';' in a single
string; multi-line scripts tend to be more portable;
- Do not use one-or-more "\+", that's not BRE.
I would propose doing the attached patch on top of yours.
Opinion?
[Footnotes]
*1* http://www.opengroup.org/onlinepubs/000095399/utilities/sed.html
*2* http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap09.html#tag_09_03
---
git-rebase.sh | 5 +----
t/t3406-rebase-message.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 9cf0056..3bd66b0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -69,13 +69,10 @@ continue_merge () {
die "$RESOLVEMSG"
fi
printf "Committed: %0${prec}d " $msgnum
- git rev-list --pretty=oneline -1 HEAD | \
- sed 's/^[a-f0-9]\+ //'
else
printf "Already applied: %0${prec}d " $msgnum
- git rev-list --pretty=oneline -1 "$cmt" | \
- sed 's/^[a-f0-9]\+ //'
fi
+ git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'
prev_head=`git rev-parse HEAD^0`
# save the resulting commit so we can read-tree on it later
diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh
new file mode 100755
index 0000000..332b2b2
--- /dev/null
+++ b/t/t3406-rebase-message.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+test_description='messages from rebase operation'
+
+. ./test-lib.sh
+
+quick_one () {
+ echo "$1" >"file$1" &&
+ git add "file$1" &&
+ test_tick &&
+ git commit -m "$1"
+}
+
+test_expect_success setup '
+ quick_one O &&
+ git branch topic &&
+ quick_one X &&
+ quick_one A &&
+ quick_one B &&
+ quick_one Y &&
+
+ git checkout topic &&
+ quick_one A &&
+ quick_one B &&
+ quick_one Z
+
+'
+
+cat >expect <<\EOF
+Already applied: 0001 A
+Already applied: 0002 B
+Committed: 0003 Z
+EOF
+
+test_expect_success 'rebase -m' '
+
+ git rebase -m master >report &&
+ sed -n -e "/^Already applied: /p" \
+ -e "/^Committed: /p" report >actual &&
+ diff -u expect actual
+
+'
+
+test_done
^ permalink raw reply related
* [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Junio C Hamano @ 2007-09-01 9:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin
In-Reply-To: <7vmyw6u5ca.fsf@gitster.siamese.dyndns.org>
This is a continuation of the other one to avoid one-or-more operator
in sed. At the same time, it actually tightens error checking,
because the numbers in the squash messages are not padded with
leading zero and cannot begin with 0.
With this, I think we do not have any more use of one-or-more
(\+) in sed scripts.
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ec798a1..abc2b1c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -190,7 +190,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
- COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
+ COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
< "$SQUASH_MSG" | tail -n 1)+1))
echo "# This is a combination of $COUNT commits."
sed -n "2,\$p" < "$SQUASH_MSG"
^ permalink raw reply related
* Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.
From: David Kastrup @ 2007-09-01 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vmyw6u5ca.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I would propose doing the attached patch on top of yours.
> Opinion?
>
> + git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'
What about
git-rev-list --pretty=format:%s -1 "$cmt"
It seems pretty pointless to first print with a wrong format, then fix
it up afterwards.
Incidentally, the above spews out a full commit line before the entry
(meaning this does not work with current git-rev-list). This is
arguably wrong: when format: is employed, the user presumably knows
perfectly well what he wants printed.
So I guess I vouch for both not using sed as well as what I consider
fixing git-rev-list --pretty=format:
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-svn: fix dcommit clobbering upstream when committing multiple changes
From: Eric Wong @ 2007-09-01 9:33 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20070901054321.GA8021@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> wrote:
> On 2007-08-31 18:16:12 -0700, Eric Wong wrote:
>
> > Although dcommit could detect if the first commit in the series
> > would conflict with the HEAD revision in SVN, it could not detect
> > conflicts in further commits it made.
> >
> > Now we rebase each uncommitted change after each revision is
> > committed to SVN to ensure that we are up-to-date. git-rebase will
> > bail out on conflict errors if our next change cannot be applied and
> > committed to SVN cleanly, preventing accidental clobbering of
> > changes on the SVN-side.
> >
> > --no-rebase users will have trouble with this, and are thus warned
> > if they are committing more than one commit. Fixing this for
> > (hopefully uncommon) --no-rebase users would be more complex and
> > will probably happen at a later date.
>
> Shouldn't it be a simple matter of checking if the total diff over the
> whole series would conflict with the SVN HEAD?
I don't think you can actually check for SVN conflicts until attempting
to do commit.
--
Eric Wong
^ permalink raw reply
* [PATCH] URL: allow port specification in ssh:// URLs
From: Luben Tuikov @ 2007-09-01 9:36 UTC (permalink / raw)
To: git
Allow port specification in ssh:// URLs in the
usual notation:
ssh://[user@]host.domain[:<port>]/<path>
This allows git to be used over ssh-tunneling
networks.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
Documentation/urls.txt | 4 +++-
connect.c | 30 +++++++++++++++++++++++++++++-
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index b38145f..e67f914 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -10,6 +10,7 @@ to name the remote repository:
- https://host.xz/path/to/repo.git/
- git://host.xz/path/to/repo.git/
- git://host.xz/~user/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
- ssh://{startsb}user@{endsb}host.xz/path/to/repo.git/
- ssh://{startsb}user@{endsb}host.xz/~user/path/to/repo.git/
- ssh://{startsb}user@{endsb}host.xz/~/path/to/repo.git
@@ -18,7 +19,8 @@ to name the remote repository:
SSH is the default transport protocol over the network. You can
optionally specify which user to log-in as, and an alternate,
scp-like syntax is also supported. Both syntaxes support
-username expansion, as does the native git protocol. The following
+username expansion, as does the native git protocol, but
+only the former supports port specification. The following
three are identical to the last three above, respectively:
===============================================================
diff --git a/connect.c b/connect.c
index ae49c5a..8b1e993 100644
--- a/connect.c
+++ b/connect.c
@@ -453,6 +453,22 @@ static void git_proxy_connect(int fd[2], char *host)
#define MAX_CMD_LEN 1024
+char *get_port(char *host)
+{
+ char *end;
+ char *p = strchr(host, ':');
+
+ if (p) {
+ strtol(p+1, &end, 10);
+ if (*end == '\0') {
+ *p = '\0';
+ return p+1;
+ }
+ }
+
+ return NULL;
+}
+
/*
* This returns 0 if the transport protocol does not need fork(2),
* or a process id if it does. Once done, finish the connection
@@ -471,6 +487,7 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
pid_t pid;
enum protocol protocol = PROTO_LOCAL;
int free_path = 0;
+ char *port = NULL;
/* Without this we cannot rely on waitpid() to tell
* what happened to our children.
@@ -527,6 +544,12 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
*ptr = '\0';
}
+ /*
+ * Add support for ssh port: ssh://host.xy:<port>/...
+ */
+ if (protocol == PROTO_SSH && host != url)
+ port = get_port(host);
+
if (protocol == PROTO_GIT) {
/* These underlying connection commands die() if they
* cannot connect.
@@ -583,7 +606,12 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
ssh_basename = ssh;
else
ssh_basename++;
- execlp(ssh, ssh_basename, host, command, NULL);
+
+ if (!port)
+ execlp(ssh, ssh_basename, host, command, NULL);
+ else
+ execlp(ssh, ssh_basename, "-p", port, host,
+ command, NULL);
}
else {
unsetenv(ALTERNATE_DB_ENVIRONMENT);
--
1.5.3.rc7.1278.g0f6d
^ permalink raw reply related
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Junio C Hamano @ 2007-09-01 9:40 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <hcmesrse.fsf@cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> Like:
>
> HEAD, HEAD~1, HEAD~2
>
> If the syntax is changed in the middle (as it was in manual page),
> that interrupts the kognitive flow of reading.
>
> HEAD, HEAD^, HEAD~2
>
I still would prefer to teach people HEAD^ earlier. If you _REALLY_
insist, I can live with spelling the HEAD~2 as HEAD^^ for
consistency.
Wasn't with you that earlier I discussed that very basic things
such as revision naming and range notation should be moved from
rev-list documentation to more central place, and sructure the
documentation in such a way that these should be read even
before individual manual pages are consulted? If we follow
that, then by the time people read these examples, they _ought_
to know that HEAD~1 is a longer-to-type way to say HEAD^ already.
^ permalink raw reply
* Re: [PATCH] URL: allow port specification in ssh:// URLs
From: Junio C Hamano @ 2007-09-01 10:15 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <583261.77513.qm@web31802.mail.mud.yahoo.com>
Nicely done.
Although none of this may be strictly necessary (you can always
add entries to ~/.ssh/config), people often got confused because
we did not support this syntax.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-svn: fix dcommit clobbering upstream when committing multiple changes
From: Karl Hasselström @ 2007-09-01 10:24 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20070901093303.GA9867@soma>
On 2007-09-01 02:33:03 -0700, Eric Wong wrote:
> Karl Hasselström <kha@treskal.com> wrote:
>
> > Shouldn't it be a simple matter of checking if the total diff over
> > the whole series would conflict with the SVN HEAD?
>
> I don't think you can actually check for SVN conflicts until
> attempting to do commit.
Ah, that's true. I was only considering the git side ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Improve the first rebase illustration with command example
From: Jari Aalto @ 2007-09-01 10:58 UTC (permalink / raw)
To: git
The case where rebasing need arises was not previously explained. The
first illustration was broadened to contain complete set of commands
and explanatory commentary how to synchronize current branch development
with new upstream changes.
The patch does not do justice, because the overall structure of the
manual was changes as well. Changes:
- Take out the examples from DESCRIPTION and move them after the
OPTIONS, under new heading EXAMPLES.
- Number the examples 1, 2, 3 and make each one separate topic
- Broaden the example 1 illustration with commands.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-rebase.txt | 212 +++++++++++++++++++++++++-----------------
1 files changed, 125 insertions(+), 87 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index a1b6dce..71c2266 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -36,21 +36,130 @@ that caused the merge failure with `git rebase --skip`. To restore the
original <branch> and remove the .dotest working files, use the command
`git rebase --abort` instead.
-Assume the following history exists and the current branch is "topic":
+In case of conflict, git-rebase will stop at the first problematic commit
+and leave conflict markers in the tree. You can use git diff to locate
+the markers (<<<<<<) and make edits to resolve the conflict. For each
+file you edit, you need to tell git that the conflict has been resolved,
+typically this would be done with
+
+
+ git add <filename>
+
+
+After resolving the conflict manually and updating the index with the
+desired resolution, you can continue the rebasing process with
+
+
+ git rebase --continue
+
+
+Alternatively, you can undo the git-rebase with
+
+
+ git rebase --abort
+
+OPTIONS
+-------
+<newbase>::
+ Starting point at which to create the new commits. If the
+ --onto option is not specified, the starting point is
+ <upstream>. May be any valid commit, and not just an
+ existing branch name.
+
+<upstream>::
+ Upstream branch to compare against. May be any valid commit,
+ not just an existing branch name.
+
+<branch>::
+ Working branch; defaults to HEAD.
+
+--continue::
+ Restart the rebasing process after having resolved a merge conflict.
+
+--abort::
+ Restore the original branch and abort the rebase operation.
+
+--skip::
+ Restart the rebasing process by skipping the current patch.
+
+--merge::
+ Use merging strategies to rebase. When the recursive (default) merge
+ strategy is used, this allows rebase to be aware of renames on the
+ upstream side.
+
+-s <strategy>, \--strategy=<strategy>::
+ Use the given merge strategy; can be supplied more than
+ once to specify them in the order they should be tried.
+ If there is no `-s` option, a built-in list of strategies
+ is used instead (`git-merge-recursive` when merging a single
+ head, `git-merge-octopus` otherwise). This implies --merge.
+
+-v, \--verbose::
+ Display a diffstat of what changed upstream since the last rebase.
+
+-C<n>::
+ Ensure at least <n> lines of surrounding context match before
+ and after each change. When fewer lines of surrounding
+ context exist they all must match. By default no context is
+ ever ignored.
+
+-i, \--interactive::
+ Make a list of the commits which are about to be rebased. Let the
+ user edit that list before rebasing.
+
+-p, \--preserve-merges::
+ Instead of ignoring merges, try to recreate them. This option
+ only works in interactive mode.
+
+include::merge-strategies.txt[]
+
+EXAMPLES
+--------
+
+EXAMPLE 1
+~~~~~~~~~
+
+Suppose you're tracking upstream development and developing a serarate
+feature that is not yet ready. You branched when upsream's HEAD was at
+E. You have progressed by 2 commits to (A,B) and working towards
+finishing commit C*. As the work is taken some time, you decide to
+update the upstream code in order to make sure you don't diverge too
+far.
+
+However, your work is unfinished and you cannot commit C* yet. We'll
+use gitlink:git-stash[1] here to assist the workflow:
------------
- A---B---C topic
- /
- D---E---F---G master
+1. git stash # Save state of branch: the incomplete C*
+2. git checkout master # switch to master, where upstream code is
+3. git pull # update master to: D-E + F-G (new changes)
+4. git checkout topic # return to previous branch
+5. git rebase master # change branch from D-E-A-B to D-E-F-G-A-B
+6. git stash apply # Bring back previously saved state C*
+
+ A---B---C* [1] [4,5] A---B [6] ---C*
+ / /
+ master D---E ........... [2,3] F---G
------------
-From this point, the result of either of the following commands:
+The command at phase 5 `git-rebase master topic` is just a short-hand
+of `git checkout topic` followed by `git rebase master`. In the end of
+phase 6, te next commit would make working branch into
+A--B--C--X--Y--D--E--F:
+Note, that If D and E does not have any interaction with what A-B-C
+are attempting, there is no reason to rebase, but some people prefer
+it because rebasing tends to keep the history clearer.
- git-rebase master
- git-rebase master topic
+So, this tree
-would be:
+------------
+ A---B---C topic
+ /
+ D---E---F---G master
+------------
+
+was effectively converted into:
------------
A'--B'--C' topic
@@ -58,8 +167,8 @@ would be:
D---E---F---G master
------------
-The latter form is just a short-hand of `git checkout topic`
-followed by `git rebase master`.
+EXAMPLE 2
+~~~~~~~~~
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
@@ -94,6 +203,9 @@ We can get this using the following command:
git-rebase --onto master next topic
+EXAMPLE 2
+~~~~~~~~~
+
Another example of --onto option is to rebase part of a
branch. If we have the following situation:
@@ -121,6 +233,9 @@ would result in:
This is useful when topicB does not depend on topicA.
+EXAMPLE 4
+~~~~~~~~~
+
A range of commits could also be removed with rebase. If we have
the following situation:
@@ -142,83 +257,6 @@ This is useful if F and G were flawed in some way, or should not be
part of topicA. Note that the argument to --onto and the <upstream>
parameter can be any valid commit-ish.
-In case of conflict, git-rebase will stop at the first problematic commit
-and leave conflict markers in the tree. You can use git diff to locate
-the markers (<<<<<<) and make edits to resolve the conflict. For each
-file you edit, you need to tell git that the conflict has been resolved,
-typically this would be done with
-
-
- git add <filename>
-
-
-After resolving the conflict manually and updating the index with the
-desired resolution, you can continue the rebasing process with
-
-
- git rebase --continue
-
-
-Alternatively, you can undo the git-rebase with
-
-
- git rebase --abort
-
-OPTIONS
--------
-<newbase>::
- Starting point at which to create the new commits. If the
- --onto option is not specified, the starting point is
- <upstream>. May be any valid commit, and not just an
- existing branch name.
-
-<upstream>::
- Upstream branch to compare against. May be any valid commit,
- not just an existing branch name.
-
-<branch>::
- Working branch; defaults to HEAD.
-
---continue::
- Restart the rebasing process after having resolved a merge conflict.
-
---abort::
- Restore the original branch and abort the rebase operation.
-
---skip::
- Restart the rebasing process by skipping the current patch.
-
---merge::
- Use merging strategies to rebase. When the recursive (default) merge
- strategy is used, this allows rebase to be aware of renames on the
- upstream side.
-
--s <strategy>, \--strategy=<strategy>::
- Use the given merge strategy; can be supplied more than
- once to specify them in the order they should be tried.
- If there is no `-s` option, a built-in list of strategies
- is used instead (`git-merge-recursive` when merging a single
- head, `git-merge-octopus` otherwise). This implies --merge.
-
--v, \--verbose::
- Display a diffstat of what changed upstream since the last rebase.
-
--C<n>::
- Ensure at least <n> lines of surrounding context match before
- and after each change. When fewer lines of surrounding
- context exist they all must match. By default no context is
- ever ignored.
-
--i, \--interactive::
- Make a list of the commits which are about to be rebased. Let the
- user edit that list before rebasing.
-
--p, \--preserve-merges::
- Instead of ignoring merges, try to recreate them. This option
- only works in interactive mode.
-
-include::merge-strategies.txt[]
-
NOTES
-----
When you rebase a branch, you are changing its history in a way that
--
1.5.3.rc5
Available from git repository http://cante.net/~jaalto/git/git
Branch: Dcumentation/git-rebase.txt+assume-the-following-history+example
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply related
* Re: [PATCH] course/svn: Fix a link pointing to a .txt instead of its .html page
From: Petr Baudis @ 2007-09-01 11:01 UTC (permalink / raw)
To: Carlos Rica; +Cc: git
In-Reply-To: <46D8DF74.6020704@gmail.com>
On Sat, Sep 01, 2007 at 05:41:40AM CEST, Carlos Rica wrote:
> Signed-off-by: Carlos Rica <jasampler@gmail.com>
Thanks, applied.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH] URL: allow port specification in ssh:// URLs
From: Luben Tuikov @ 2007-09-01 11:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wdiu1x2.fsf@gitster.siamese.dyndns.org>
--- Junio C Hamano <gitster@pobox.com> wrote:
> Nicely done.
Thanks!
Luben
^ permalink raw reply
* [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Robin Rosenberg @ 2007-09-01 10:22 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/completion/git-completion.bash | 30 ++++++++++++++++++++++++++----
1 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5ed1821..1fef857 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -64,12 +64,34 @@ __gitdir ()
__git_ps1 ()
{
- local b="$(git symbolic-ref HEAD 2>/dev/null)"
- if [ -n "$b" ]; then
+ local g="$(git rev-parse --git-dir 2>/dev/null)"
+ if [ -n "$g" ]; then
+ local r
+ local b
+ if [ -d "$g/../.dotest" ]
+ then
+ local b="$(git symbolic-ref HEAD 2>/dev/null)"
+ r="|REBASEING"
+ else
+ if [ -d "$g/.dotest-merge" ]
+ then
+ r="|REBASING"
+ b="$(cat $g/.dotest-merge/head-name)"
+ else
+ if [ -f "$g/MERGE_HEAD" ]
+ then
+ r="|MERGING"
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+ else
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+ fi
+ fi
+ fi
+
if [ -n "$1" ]; then
- printf "$1" "${b##refs/heads/}"
+ printf "$1" "${b##refs/heads/}$r"
else
- printf " (%s)" "${b##refs/heads/}"
+ printf " (%s)" "${b##refs/heads/}$r"
fi
fi
}
--
1.5.3.rc7.844.gfd3c5
^ permalink raw reply related
* Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.
From: Johannes Sixt @ 2007-09-01 12:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vmyw6u5ca.fsf@gitster.siamese.dyndns.org>
On Saturday 01 September 2007 11:01, Junio C Hamano wrote:
> printf "Committed: %0${prec}d " $msgnum
> - git rev-list --pretty=oneline -1 HEAD | \
> - sed 's/^[a-f0-9]\+ //'
> else
> printf "Already applied: %0${prec}d " $msgnum
> - git rev-list --pretty=oneline -1 "$cmt" | \
> - sed 's/^[a-f0-9]\+ //'
> fi
> + git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'
I prefer this over my version as well.
-- Hannes
^ permalink raw reply
* Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.
From: Robin Rosenberg @ 2007-09-01 12:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio Hamano, git
In-Reply-To: <200709010925.27926.johannes.sixt@telecom.at>
Just so we know what the '-m' is from the documentation.
-- robin
>From b4fd5fca1aa45183c04327a29ee98d01a4e76e59 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Sat, 1 Sep 2007 13:52:26 +0200
Subject: [PATCH] Mention -m as an abbreviation for --merge
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-rebase.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index a1b6dce..cb87b03 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -8,7 +8,7 @@ git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------
[verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [--merge] [-C<n>]
+'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] [-C<n>]
[-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
@@ -188,7 +188,7 @@ OPTIONS
--skip::
Restart the rebasing process by skipping the current patch.
---merge::
+-m, \--merge::
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side.
--
1.5.3.rc7.844.gfd3c5
^ permalink raw reply related
* Re: [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Carlos Rica @ 2007-09-01 14:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <7v8x7qvrka.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
2007/9/1, Junio C Hamano <gitster@pobox.com>:
> I think it is conceptually simpler on the show_reference side to
> allow (filter.pattern == NULL) and say:
>
> if (!filter->pattern || !fnmatch(filter->pattern, refname, 0)) {
> ... show that ref ...
> }
>
> It is not such a big deal now you do not do newpattern
> allocation anymore, so I'll apply the patch as is.
>
You are right. I changed the patch also to reflect this.
I cannot send a reply using my email client now, so I send it
attached to this response to avoid gmail breaks in long lines.
[-- Attachment #2: 0001-git-tag-Fix-l-option-to-use-better-shell-style-globs.patch --]
[-- Type: text/x-patch, Size: 3992 bytes --]
From d10170c5a2c3cf1fc6ad270e9a2c82ff29a98871 Mon Sep 17 00:00:00 2001
From: Carlos Rica <jasampler@gmail.com>
Date: Sat, 1 Sep 2007 06:58:40 +0200
Subject: [PATCH] git-tag: Fix -l option to use better shell style globs.
This patch removes the behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring. The same
thing now could be achieved doing "git tag -l '*foo*'".
The "feature" was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.
Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substr*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.
Tests for "git tag" were also changed to reflect this.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
builtin-tag.c | 14 ++------------
t/t7004-tag.sh | 20 +++++++++-----------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index d6d38ad..0e01b98 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -75,7 +75,7 @@ static int show_reference(const char *refname, const unsigned char *sha1,
{
struct tag_filter *filter = cb_data;
- if (!fnmatch(filter->pattern, refname, 0)) {
+ if (!filter->pattern || !fnmatch(filter->pattern, refname, 0)) {
int i;
unsigned long size;
enum object_type type;
@@ -123,22 +123,12 @@ static int show_reference(const char *refname, const unsigned char *sha1,
static int list_tags(const char *pattern, int lines)
{
struct tag_filter filter;
- char *newpattern;
- if (pattern == NULL)
- pattern = "";
-
- /* prepend/append * to the shell pattern: */
- newpattern = xmalloc(strlen(pattern) + 3);
- sprintf(newpattern, "*%s*", pattern);
-
- filter.pattern = newpattern;
+ filter.pattern = pattern;
filter.lines = lines;
for_each_tag_ref(show_reference, (void *) &filter);
- free(newpattern);
-
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index c4fa446..606d4f2 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -185,18 +185,17 @@ cba
EOF
test_expect_success \
'listing tags with substring as pattern must print those matching' '
- git-tag -l a > actual &&
+ git-tag -l "*a*" > actual &&
git diff expect actual
'
cat >expect <<EOF
v0.2.1
v1.0.1
-v1.1.3
EOF
test_expect_success \
- 'listing tags with substring as pattern must print those matching' '
- git-tag -l .1 > actual &&
+ 'listing tags with a suffix as pattern must print those matching' '
+ git-tag -l "*.1" > actual &&
git diff expect actual
'
@@ -205,37 +204,36 @@ t210
t211
EOF
test_expect_success \
- 'listing tags with substring as pattern must print those matching' '
- git-tag -l t21 > actual &&
+ 'listing tags with a prefix as pattern must print those matching' '
+ git-tag -l "t21*" > actual &&
git diff expect actual
'
cat >expect <<EOF
a1
-aa1
EOF
test_expect_success \
- 'listing tags using a name as pattern must print those matching' '
+ 'listing tags using a name as pattern must print that one matching' '
git-tag -l a1 > actual &&
git diff expect actual
'
cat >expect <<EOF
v1.0
-v1.0.1
EOF
test_expect_success \
- 'listing tags using a name as pattern must print those matching' '
+ 'listing tags using a name as pattern must print that one matching' '
git-tag -l v1.0 > actual &&
git diff expect actual
'
cat >expect <<EOF
+v1.0.1
v1.1.3
EOF
test_expect_success \
'listing tags with ? in the pattern should print those matching' '
- git-tag -l "1.1?" > actual &&
+ git-tag -l "v1.?.?" > actual &&
git diff expect actual
'
--
1.5.0
^ permalink raw reply related
* Re: [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Carlos Rica @ 2007-09-01 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1b46aba20709010733x45960f00g8732f6a1af363768@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
2007/9/1, Carlos Rica <jasampler@gmail.com>:
> You are right. I changed the patch also to reflect this.
Sorry, it seems that it also has a different "version" of
my comments for the commit, I have the good/bad habit of
reading again the comments in patches (and changing them)
before send it out to the list...
6c6
This patch removes certain behaviour of "git tag -l foo", currently
This patch removes the behaviour of "git tag -l foo", currently
10c10
This feature was added recently when git-tag.sh got the -n option
The "feature" was added recently when git-tag.sh got the -n option
18c18
_only_ when * is inserted before and after (as in "*substring*"), and
_only_ when * is inserted before and after (as in "*substr*"), and
[-- Attachment #2: 0001-git-tag-Fix-l-option-to-use-better-shell-style-globs.patch --]
[-- Type: text/x-patch, Size: 3998 bytes --]
From ea881fdfd39ce5fb5aaa273d90c6bf8ed5f8d9b0 Mon Sep 17 00:00:00 2001
From: Carlos Rica <jasampler@gmail.com>
Date: Sat, 1 Sep 2007 06:58:40 +0200
Subject: [PATCH] git-tag: Fix -l option to use better shell style globs.
This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring. The same
thing now could be achieved doing "git tag -l '*foo*'".
This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.
Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.
Tests for "git tag" were also changed to reflect this.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
builtin-tag.c | 14 ++------------
t/t7004-tag.sh | 20 +++++++++-----------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index d6d38ad..0e01b98 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -75,7 +75,7 @@ static int show_reference(const char *refname, const unsigned char *sha1,
{
struct tag_filter *filter = cb_data;
- if (!fnmatch(filter->pattern, refname, 0)) {
+ if (!filter->pattern || !fnmatch(filter->pattern, refname, 0)) {
int i;
unsigned long size;
enum object_type type;
@@ -123,22 +123,12 @@ static int show_reference(const char *refname, const unsigned char *sha1,
static int list_tags(const char *pattern, int lines)
{
struct tag_filter filter;
- char *newpattern;
- if (pattern == NULL)
- pattern = "";
-
- /* prepend/append * to the shell pattern: */
- newpattern = xmalloc(strlen(pattern) + 3);
- sprintf(newpattern, "*%s*", pattern);
-
- filter.pattern = newpattern;
+ filter.pattern = pattern;
filter.lines = lines;
for_each_tag_ref(show_reference, (void *) &filter);
- free(newpattern);
-
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index c4fa446..606d4f2 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -185,18 +185,17 @@ cba
EOF
test_expect_success \
'listing tags with substring as pattern must print those matching' '
- git-tag -l a > actual &&
+ git-tag -l "*a*" > actual &&
git diff expect actual
'
cat >expect <<EOF
v0.2.1
v1.0.1
-v1.1.3
EOF
test_expect_success \
- 'listing tags with substring as pattern must print those matching' '
- git-tag -l .1 > actual &&
+ 'listing tags with a suffix as pattern must print those matching' '
+ git-tag -l "*.1" > actual &&
git diff expect actual
'
@@ -205,37 +204,36 @@ t210
t211
EOF
test_expect_success \
- 'listing tags with substring as pattern must print those matching' '
- git-tag -l t21 > actual &&
+ 'listing tags with a prefix as pattern must print those matching' '
+ git-tag -l "t21*" > actual &&
git diff expect actual
'
cat >expect <<EOF
a1
-aa1
EOF
test_expect_success \
- 'listing tags using a name as pattern must print those matching' '
+ 'listing tags using a name as pattern must print that one matching' '
git-tag -l a1 > actual &&
git diff expect actual
'
cat >expect <<EOF
v1.0
-v1.0.1
EOF
test_expect_success \
- 'listing tags using a name as pattern must print those matching' '
+ 'listing tags using a name as pattern must print that one matching' '
git-tag -l v1.0 > actual &&
git diff expect actual
'
cat >expect <<EOF
+v1.0.1
v1.1.3
EOF
test_expect_success \
'listing tags with ? in the pattern should print those matching' '
- git-tag -l "1.1?" > actual &&
+ git-tag -l "v1.?.?" > actual &&
git diff expect actual
'
--
1.5.0
^ permalink raw reply related
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Shawn Bohrer @ 2007-09-01 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vabs6u3jt.fsf@gitster.siamese.dyndns.org>
On Sat, Sep 01, 2007 at 02:40:22AM -0700, Junio C Hamano wrote:
> Jari Aalto <jari.aalto@cante.net> writes:
>
> > Like:
> >
> > HEAD, HEAD~1, HEAD~2
> >
> > If the syntax is changed in the middle (as it was in manual page),
> > that interrupts the kognitive flow of reading.
> >
> > HEAD, HEAD^, HEAD~2
> >
>
> I still would prefer to teach people HEAD^ earlier. If you _REALLY_
> insist, I can live with spelling the HEAD~2 as HEAD^^ for
> consistency.
>
> Wasn't with you that earlier I discussed that very basic things
> such as revision naming and range notation should be moved from
> rev-list documentation to more central place, and sructure the
> documentation in such a way that these should be read even
> before individual manual pages are consulted? If we follow
> that, then by the time people read these examples, they _ought_
> to know that HEAD~1 is a longer-to-type way to say HEAD^ already.
Well I am a new user to git and I didn't find the mixed notation
confusing at all. Perhaps this is because I read the tutorial first,
then the git user manual which both explain this clearly.
In either case I think eliminating either notation from the man pages is
a bad idea. I'm quite confident that in the worst case a user will
think that if they want to refer to the parent they have to say HEAD^
and if they want to refer to the grandparent they have to say HEAD~2.
Most won't even find that strange since HEAD^ just seems shorter. I
also think many users will be smart enough to infer that if they wanted
to they could say HEAD~3 or perhaps HEAD~1, though unless I saw it
somewhere I might not have guessed HEAD^^.
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Jon Smirl @ 2007-09-01 15:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, jnareb, ltuikov
In-Reply-To: <20070831000149.GK1219@pasky.or.cz>
On 8/30/07, Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> of git at repo.or.cz:
>
> http://repo.or.cz/w/git/gitweb.git
>
> It is meant as a hub for various gitweb-related patches and
> development efforts. So far it is pre-seeded by the patches repo.or.cz's
> gitweb uses. It is divided to three main branches (StGIT patchstacks in
> reality), where master is what Junio is gonna pull to git's master.
Using gitweb....
Since this is a patch stack, how do I get the summary log messages for
just the commits on the branch without getting the log messages for
the master repository mixed in? Would that give me a nice list of the
pending patches?
I can get the tree diffs without problem.
>
> Please feel encouraged to make random forks for your development
> efforts, or push your random patches (preferrably just bugfixes,
> something possibly controversial should be kept in safe containment like
> a fork or separate branch) to the mob branch.
>
> Have fun,
>
> --
> Petr "Pasky" Baudis
> Early to rise and early to bed makes a male healthy and wealthy and dead.
> -- James Thurber
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Junio C Hamano @ 2007-09-01 17:54 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, git, jnareb, ltuikov
In-Reply-To: <9e4733910709010815t23849056j9039a9d92eae15ee@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> On 8/30/07, Petr Baudis <pasky@suse.cz> wrote:
>>
>> due to popular (Junio's) demand, I have set up a gitweb-oriented fork
>> of git at repo.or.cz:
>>
>> http://repo.or.cz/w/git/gitweb.git
>>
>> It is meant as a hub for various gitweb-related patches and
>> development efforts. So far it is pre-seeded by the patches repo.or.cz's
>> gitweb uses. It is divided to three main branches (StGIT patchstacks in
>> reality), where master is what Junio is gonna pull to git's master.
>
> Using gitweb....
> Since this is a patch stack, how do I get the summary log messages for
> just the commits on the branch without getting the log messages for
> the master repository mixed in? Would that give me a nice list of the
> pending patches?
That's an excellent suggestion. I'd love to see "fork" aware
gitweb myself.
If a project A is "forked" repo.or.cz style to a project B, what
often is interesting to see is what changes B has relative to A.
In other words, you would want to view all of B except what are
in A, something like:
$ gitk --all --not $(git for-each-ref --format='%(objectname)' refs/remotes/A)
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Junio C Hamano @ 2007-09-01 18:07 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: spearce, git
In-Reply-To: <11886421573285-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 5ed1821..1fef857 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -64,12 +64,34 @@ __gitdir ()
>
> __git_ps1 ()
> {
> - local b="$(git symbolic-ref HEAD 2>/dev/null)"
> - if [ -n "$b" ]; then
> + local g="$(git rev-parse --git-dir 2>/dev/null)"
> + if [ -n "$g" ]; then
> + local r
> + local b
> + if [ -d "$g/../.dotest" ]
> + then
> + local b="$(git symbolic-ref HEAD 2>/dev/null)"
> + r="|REBASEING"
I might be in the middle of resolving a conflicted "git am".
But I love the idea. We need to think about cleaning up our
"state machine" mechanism to make this kind of thing easier to
do. We've had a few suggestions on the list in the past but
they never passed the suggestion/speculation stage.
^ permalink raw reply
* Re: [PATCH] Improve the first rebase illustration with command example
From: Junio C Hamano @ 2007-09-01 20:04 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <bqcmsld7.fsf@cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> The case where rebasing need arises was not previously explained. The
> first illustration was broadened to contain complete set of commands
> and explanatory commentary how to synchronize current branch development
> with new upstream changes.
>
> The patch does not do justice, because the overall structure of the
> manual was changes as well. Changes:
>
> - Take out the examples from DESCRIPTION and move them after the
> OPTIONS, under new heading EXAMPLES.
> - Number the examples 1, 2, 3 and make each one separate topic
> - Broaden the example 1 illustration with commands.
>
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Thanks for a patch. I tried to rebase it on top of 'master',
but then noticed a few things.
> +In case of conflict, git-rebase will stop at the first problematic commit
> +and leave conflict markers in the tree. You can use git diff to locate
> +the markers (<<<<<<) and make edits to resolve the conflict. For each
> +file you edit, you need to tell git that the conflict has been resolved,
> +typically this would be done with
> +
> +
> + git add <filename>
> +
> +
Do not need nor want two blank lines around these examples; one
each should be enough.
> +After resolving the conflict manually and updating the index with the
> +desired resolution, you can continue the rebasing process with
> ...
> +Alternatively, you can undo the git-rebase with
> +
> + git rebase --abort
That's already there in the previous paragraph that begins with
"It is possible that a merge failure will prevent this process
from being completely automatic", but I think it makes sense to
present the way you did to make each of them to stand out more.
Perhaps we would want to remove the second and later sentences
from that paragraph.
> +include::merge-strategies.txt[]
> +
> +EXAMPLES
> +--------
> +
> +EXAMPLE 1
> +~~~~~~~~~
> +
> +Suppose you're tracking upstream development and developing a serarate
> +feature that is not yet ready. You branched when upsream's HEAD was at
> +E. You have progressed by 2 commits to (A,B) and working towards
> +finishing commit C*. As the work is taken some time, you decide to
> +update the upstream code in order to make sure you don't diverge too
> +far.
> +
> +However, your work is unfinished and you cannot commit C* yet. We'll
> +use gitlink:git-stash[1] here to assist the workflow:
> +
> ------------
> +1. git stash # Save state of branch: the incomplete C*
> +2. git checkout master # switch to master, where upstream code is
> +3. git pull # update master to: D-E + F-G (new changes)
> +4. git checkout topic # return to previous branch
> +5. git rebase master # change branch from D-E-A-B to D-E-F-G-A-B
> +6. git stash apply # Bring back previously saved state C*
> +
> + A---B---C* [1] [4,5] A---B [6] ---C*
> + / /
> + master D---E ........... [2,3] F---G
> ------------
>
> +The command at phase 5 `git-rebase master topic` is just a short-hand
> +of `git checkout topic` followed by `git rebase master`. In the end of
> +phase 6, te next commit would make working branch into
> +A--B--C--X--Y--D--E--F:
You don't. You would make D-E-F-G-A-B-C.
It would be much easier for new users to read if our examples
start from simpler and progress to more complex. It appears that
the use of stash in this example (only because the example
assumes you are in the middle of something that is unfinished)
complicates description without merit.
After the user understands the workflow that starts from having
A-B and with clean working tree, IOW, your steps 2 through 5,
managing the situation where you have that dirty state C* comes
as a very natural extension of what he already knows, and at
that point, it does not matter to your use of stash/unstash what
you do between steps 2-5. You stash because you are going to do
anything complicated, and the details of that complicated stuff
does not matter why surrounding that sequence with stash/unstash
pair is useful. In yet another words, the pair of steps 1 and 6
and the rest are orthogonal issues.
So what I would want to see in this example, if you wanted to
talk about the way git-stash can be used in conjunction with
git-rebase, would be something like this:
-- clipcrop -- >8 -- clipcrop --
EXAMPLE 1
~~~~~~~~~
Suppose you're tracking upstream development and developing a serarate
feature that is not yet ready. You started when upsream's HEAD was at
E. You have progressed by 2 commits to (A,B).
Because your work A and B have some interactions to what has
been done at the upstream in the meantime, you decide to update
the upstream code in order to make sure you don't diverge too
far.
------------
1. git checkout master # switch to master, where upstream code is
2. git pull # update master to: D-E + F-G (new changes)
3. git checkout topic # return to previous branch
4. git rebase master # change branch from D-E-A-B to D-E-F-G-A'-B'
A---B [3] A'--B' [4]
/ /
master D---E [1] ---------- F---G [2]
------------
The command at step 4 `git-rebase master topic` is just a short-hand
of `git checkout topic` followed by `git rebase master`. When
you are done, your topic branch has two commits on top of the
updated master.
Note, that If D and E does not have any interaction with what
your topic are attempting to achieve, there is no reason to
rebase, but some people prefer it because rebasing tends to keep
the history clearer.
If you are in the middle of building some more stuff on top of
B but not committed yet, rebase will refuse to run. You can use
gitlink:git-stash[1] to help you in such a case.
------------
0. git stash
1...4 (the same as before)
5. git stash apply
A---B---C* [0] A'--B'--C*
/ /
master D---E [1] ---------- F---G [2]
------------
What happens to A, B, D, E, F and G is exactly the same as
before. The only difference is that your work-in-progress
(depicted as `C*` in the above, the work you did since `B`) is
saved away first, and then reapplied on top of updated `B`.
In short, the above procedure would transform this history
structure:
------------
A---B---C* topic
/
D---E---F---G* master
------------
into this:
------------
A'--B'--C' topic
/
D---E---F---G master
------------
^ permalink raw reply
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Jari Aalto @ 2007-09-01 20:40 UTC (permalink / raw)
To: git
In-Reply-To: <20070901150153.GD7422@mediacenter.austin.rr.com>
Shawn Bohrer <shawn.bohrer@gmail.com> writes:
> On Sat, Sep 01, 2007 at 02:40:22AM -0700, Junio C Hamano wrote:
>
>> Jari Aalto <jari.aalto@cante.net> writes:
>>
>> > Like:
>> >
>> > HEAD, HEAD~1, HEAD~2
>> >
>> > If the syntax is changed in the middle (as it was in manual page),
>> > that interrupts the kognitive flow of reading.
>> >
>> > HEAD, HEAD^, HEAD~2
>> >
>>
>> I still would prefer to teach people HEAD^ earlier. If you _REALLY_
>> insist, I can live with spelling the HEAD~2 as HEAD^^ for
>> consistency.
>
> Well I am a new user to git and I didn't find the mixed notation
> confusing at all. Perhaps this is because I read the tutorial first,
> then the git user manual which both explain this clearly.
Naturally one's learning path is naturally different. Did you come
from other SCM/VCS before intorduced to git?
> In either case I think eliminating either notation from the man pages is
> a bad idea.
That was not proposed. There a mnay pages that use and shoudl use the
^ notations. I was proposing that only (git-COMMAND) were dealt with.
After all, the ^ very differento to what other SCM/VCSs use.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ 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