Re: [PATCH 6/7] sha1_name: cleanup interpret_branch_name()
From: Felipe Contreras felipe.contre...@gmail.com
The 'upstream' variable doesn't hold an upstream, but a branch, so
make it clearer.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index e9c2999..e27db88 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1072,7 +1072,7 @@ static int reinterpret(const char *name, int
namelen, int len, struct strbuf *bu
int interpret_branch_name(const char *name, int namelen, struct strbuf
*buf)
{
char *cp;
- struct branch *upstream;
+ struct branch *branch;
int len = interpret_nth_prior_checkout(name, buf);
int tmp_len;
@@ -1102,26 +1102,26 @@ int interpret_branch_name(const char *name,
int namelen, struct strbuf *buf)
len = cp + tmp_len - name;
cp = xstrndup(name, cp - name);
- upstream = branch_get(*cp ? cp : NULL);
+ branch = branch_get(*cp ? cp : NULL);
/*
* Upstream can be NULL only if cp refers to HEAD and HEAD
* points to something different than a branch.
Doesn't this comment also need updating, or at least clarifying any
contradictions between variable names and the concepts described. That
is does Upstream refer to the original variable 'upstream', and now
the final branch can be confused with the new variable name.
I'm not arguing against the change, rather just noting an additional
consequence.
*/
- if (!upstream)
+ if (!branch)
die(_(HEAD does not point to a branch));
- if (!upstream-merge || !upstream-merge[0]-dst) {
- if (!ref_exists(upstream-refname))
+ if (!branch-merge || !branch-merge[0]-dst) {
+ if (!ref_exists(branch-refname))
die(_(No such branch: '%s'), cp);
- if (!upstream-merge) {
+ if (!branch-merge) {
die(_(No upstream configured for branch '%s'),
- upstream-name);
+ branch-name);
}
die(
_(Upstream branch '%s' not stored as a remote-tracking branch),
- upstream-merge[0]-src);
+ branch-merge[0]-src);
}
free(cp);
- cp = shorten_unambiguous_ref(upstream-merge[0]-dst, 0);
+ cp = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
strbuf_reset(buf);
strbuf_addstr(buf, cp);
free(cp);
--
1.8.5.1+fc1.2.gebd1fb1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Karsten Blees karsten.bl...@gmail.com writes: Am 07.12.2013 23:23, schrieb Thomas Rast: Karsten Blees karsten.bl...@gmail.com writes: Extending 'struct hashmap_entry' with an int-sized member shouldn't waste memory on 64-bit systems. This is already documented in api-hashmap.txt, but needs '__attribute__((__packed__))' to work. Reduces e.g. You'd have to guard __attribute__((__packed__)) with some compiler detection in git-compat-util.h though. Isn't that already handled? __attribute__ is already widely used (e.g. for printf formats), and platforms that don't support it define it as empty (e.g. MSVC). Or do you mean I should account for compiler-specific variants (#pragma pack...)? True, __attribute__ expands to nothing on unknown compilers, but what does the compiler do when it sees an unknown attribute? If some of them choke, you need a separate macro. I'm a bit confused myself though, many attributes have special macros in git-compat-util.h but others we just use in the code. -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pull: use merge-base --fork-point when appropriate
Since commit d96855f (merge-base: teach --fork-point mode, 2013-10-23)
we can replace a shell loop in git-pull with a single call to
git-merge-base. So let's do so.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-pull.sh | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index b946fd9..605e957 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -229,15 +229,7 @@ test true = $rebase {
test -n $curr_branch
. git-parse-remote
remoteref=$(get_remote_merge_branch $@ 2/dev/null)
- oldremoteref=$(git rev-parse -q --verify $remoteref)
- for reflog in $(git rev-list -g $remoteref 2/dev/null)
- do
- if test $reflog = $(git merge-base $reflog $curr_branch)
- then
- oldremoteref=$reflog
- break
- fi
- done
+ oldremoteref=$(git merge-base --fork-point $remoteref $curr_branch)
}
orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok
$@ || exit 1
--
1.8.5.226.g0d60d77
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please Confirm
Greetings to you, I want you to assist me in transferring the sum of US$9.5M left behind by my dead client. I am willing to offer 50% to you as the sole beneficiary after the funds has been transferred to you. Get back to me if you are interested so that i can provide you with more details Regards, Jack Kofi, esq -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-subtree manpage missing from git-manpages tarballs
The git-subtree manpage is currently missing from the git-manpages tarballs at https://code.google.com/p/git-core/. For example, https://code.google.com/p/git-core/downloads/detail?name=git-manpages-1.8.5.1.tar.gz does not include it. A side effect of this is that git help subtree fails when using git installed from homebrew, because the homebrew recipe uses those tarballs as its source of documentation. Is it possible to include the manpage starting with an upcoming release, or is there a good reason it's excluded? Thanks, Stefanus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] rebase: use reflog to find common base with upstream
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream}'. That is also what
'git pull [--rebase]' defaults to, so it only makes sense that
'git rebase' defaults to the same thing.
but that isn't actually the case. Since commit d44e712 (pull: support
rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
chosen the most recent reflog entry which is an ancestor of the current
branch if it can find one.
Change rebase so that it uses the same logic, but only when no upstream
argument is given on the command line.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Last time this came up [1], there was some discussion about moving the
added block of code to affect upstreams given on the command line as
well as when the upstream is discovered from the config. Having tried
that, it has some more fallout on the test suite than I like; this
pattern ends up dropping the tip commit of side because it's in the
reflog of master:
# start on master
git branch side
git reset --hard HEAD^
git checkout side
git rebase master
I wonder if it would be better to add a --fork-point argument to
git-rebase and default it to true when no upstream is given on the
command line.
[1] http://article.gmane.org/gmane.comp.version-control.git/236252
git-rebase.sh | 6 ++
t/t3400-rebase.sh | 6 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 226752f..17801ad 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -437,6 +437,12 @@ then
error_on_missing_default_upstream rebase rebase \
against git rebase branch
fi
+
+ fork_point=$(git merge-base --fork-point $upstream_name HEAD)
+ if test -n $fork_point test $fork_point != $upstream
+ then
+ upstream=$fork_point
+ fi
;;
*) upstream_name=$1
shift
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index ebf93b0..998503d 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -134,12 +134,14 @@ test_expect_success 'fail when upstream arg is missing
and not configured' '
test_must_fail git rebase
'
-test_expect_success 'default to @{upstream} when upstream arg is missing' '
+test_expect_success 'default to common base in @{upstream}s reflog if no
upstream arg' '
git checkout -b default topic
git config branch.default.remote .
git config branch.default.merge refs/heads/master
git rebase
- test $(git rev-parse default~1) = $(git rev-parse master)
+ git rev-parse --verify master expect
+ git rev-parse default~1 actual
+ test_cmp expect actual
'
test_expect_success 'rebase -q is quiet' '
--
1.8.5.226.g0d60d77
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RelNotes: fix a typo in Negotiate.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- Documentation/RelNotes/1.9.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.9.txt b/Documentation/RelNotes/1.9.txt index 9debcc4..d5c99a9 100644 --- a/Documentation/RelNotes/1.9.txt +++ b/Documentation/RelNotes/1.9.txt @@ -68,7 +68,7 @@ Updates since v1.8.5 Foreign interfaces, subsystems and ports. - * The HTTP transport, when talking GSS-Negotinate, uses 100 + * The HTTP transport, when talking GSS-Negotiate, uses 100 Continue response to avoid having to rewind and resend a large payload, which may not be always doable. -- 1.8.5.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: document pitfalls with 3-way merge
Oftentimes people will make the same change in two branches, revert the change in one branch, and then be surprised when a merge reinstitutes that change when the branches are merged. Add an explanatory paragraph that explains that this occurs and the reason why, so people are not surprised. Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- This is a documentation fix that I've been holding onto for a week or so. I noticed that a lot of people were surprised by this behavior, and figured it would be better to document it. I'm not sure that this is the right place for it, and I'm happy to take suggestions on how to improve the wording. Documentation/merge-strategies.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 49a9a7d..fb6e593 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -113,3 +113,11 @@ subtree:: match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree. + +With the strategies that use 3-way merge (including the default, 'recursive'), +if a change is made on both branches, but later reverted on one of the +branches, that change will be present in the merged result; some people find +this behavior confusing. It occurs because only the heads and the merge base +are considered when performing a merge, not the individual commits. The merge +algorithm therefore considers the reverted change as no change at all, and +substitutes the changed version instead. -- 1.8.5.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding --gpg-sign to cherry-pick, revert, am, rebase
On Sun, Nov 03, 2013 at 04:54:16PM +0100, Nicolas Vigier wrote: Hello, Here is a series of patches to add the --gpg-sign option to be able to gpg sign commits, to the cherry-pick, revert, am and rebase commands. Whatever happened to this series? It looks like it never made it into next, master, or pu, and Junio's immediately-following What's cooking email didn't mention it. I'm really very interested in seeing it merged, so if there's something I can do to help it along, please let me know. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH v1] Pull, Fetch, and Push hang for 2 minutes over https when connecting to localhost.
Bug description: On Windows, when the git client is attempting to communicate
via https to an apache server that happens to be on the same machine
(localhost), the client connection will hang for about 2 minutes before
completing. Connecting via https to non-localhost git server returns
immediately and works as desired. It is not known as to whether this is an
issue in other environments than Windows.
This behavior was observed starting with msysgit version 1.8.3 and newer and
was a result of msysgit updating the curl library from version 7.26 to version
7.28 and the problem still exists in curl version 7.33. The problem was
occurring because curl_multi_timeout() was returning a value of 148797 under
this circumstance which posed a greater than 2 minute wait before timing out in
the call to select(). Examples (curl\docs\examples\fopen.c
curl\docs\examples\multi-app.c) provided with the curl library for how to use
curl_multi_timeout() setup the timeout slightly different than how it is being
done here. Curl examples basically clip all timeouts returned from
curl_multi_timeout() at one second. The changes made with this revision change
it to follow the same clipping logic as used by the curl examples.
It should be noted that this problem appears to be very similar to a problem
Stefan Zager was having where a large timeout was returned when an invalid file
descriptor was returned.
Another thought on how to resolve this issue would have been to track down why
the curl_multi_timeout() method is returning such a large value in the curl
library and resolve it there, but being as though examples written for how to
use curl_multi_timeout() properly do not exhibit this problem in the first
place it most likely makes more sense to modify the calling logic to fix the
problem.
Signed-off-by: Rick Burgstaler rburgsta...@yahoo.com
---
diff --git a/http.c b/http.c
index 8284837..314d091 100644
--- a/http.c
+++ b/http.c
@@ -640,15 +640,18 @@ void run_active_slot(struct active_request_slot *slot)
if (slot-in_use) {
#if LIBCURL_VERSION_NUM = 0x070f04
-long curl_timeout;
+long curl_timeout = -1;
+
+/* set a suitable timeout */
+select_timeout.tv_sec = 1;
+select_timeout.tv_usec = 0;
+
curl_multi_timeout(curlm, curl_timeout);
-if (curl_timeout == 0) {
-continue;
-} else if (curl_timeout == -1) {
-select_timeout.tv_sec = 0;
-select_timeout.tv_usec = 5;
-} else {
-select_timeout.tv_sec = curl_timeout / 1000;
+if(curl_timeout = 0) {
+ select_timeout.tv_sec = curl_timeout / 1000;
+ if(select_timeout.tv_sec 1)
+select_timeout.tv_sec = 1;
+ else
select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
}
#else
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] parse-options: remove OPT_BOOLEAN
Hi, Nguyễn Thái Ngọc Duy wrote: After a86a8b9 (sb/parseopt-boolean-removal), the deprecated OPT_BOOLEAN is not used anywhere except by OPT__* macros. Yeah, I noticed the same thing too recently. [...] All OPT__DRY_RUN call sites have been checked and they look safe for OPT_BOOL. This is the only functional change from the patch. A repeated --dry-run that behaves differently from --dry-run would be very weird, and a quick check of OPT__DRY_RUN uses in pu confirms that with current callers the patch is a no-op (except in the weird case that someone overflows an int with a very long -nnn... commandline). Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-subtree manpage missing from git-manpages tarballs
Hi, Stefanus Du Toit wrote: The git-subtree manpage is currently missing from the git-manpages tarballs at https://code.google.com/p/git-core/. For example, https://code.google.com/p/git-core/downloads/detail?name=git-manpages-1.8.5.1.tar.gz does not include it. A side effect of this is that git help subtree fails when using git installed from homebrew, because the homebrew recipe uses those tarballs as its source of documentation. git-subtree and its documentation are in the contrib/subtree directory. contrib/subtree/Makefile includes rules to build a manpage for it. If the homebrew rules are installing the git-subtree command from there, perhaps they could be tweaked to build the manpage, too. What do you think? Alternatively: I'm not sure what the status of git-subtree maintenance is. Is there someone taking active enough care of it that it would make sense to promote it out of contrib/ to be a full git command installed by default? Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: document pitfalls with 3-way merge
Hi, brian m. carlson wrote: Oftentimes people will make the same change in two branches, revert the change in one branch, and then be surprised when a merge reinstitutes that change when the branches are merged. Life is even more complicated: if the merge-base chosen happens to be a descendent of the change on both branches, the merge won't reinstate the change. The problem scenario hasn't happened to me recently. Can you give an example of how it happens? Why is the same change being made independently on two different branches? I'm wondering because such a story could make the example in the documentation a little clearer and avoid having to make the explanation overly technical. In any event, that the 3-way merge is really just a stupid 3-way merge (modulo multiple merge base madness) does seem worth emphasizing, so thanks for working on this. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: document pitfalls with 3-way merge
On Sun, Dec 08, 2013 at 02:40:13PM -0800, Jonathan Nieder wrote: brian m. carlson wrote: Oftentimes people will make the same change in two branches, revert the change in one branch, and then be surprised when a merge reinstitutes that change when the branches are merged. Life is even more complicated: if the merge-base chosen happens to be a descendent of the change on both branches, the merge won't reinstate the change. Right. The text should probably be clearer in that respect. The problem scenario hasn't happened to me recently. Can you give an example of how it happens? Why is the same change being made independently on two different branches? I'm wondering because such a story could make the example in the documentation a little clearer and avoid having to make the explanation overly technical. It happens pretty much as I described. There have been two different posters to the list who have made the same change on both branches, reverted it on one, and then were surprised when it was reinstated during the merge. Generally people expect conflicts in this case. I don't have any further details, since it hasn't happened to me and I'm not either one of those posters, but I suspect if someone did a cherry-pick of a change from one branch to another that could happen. Maybe an important bug fix was picked from a topic branch, but the change was reverted because the problem was solved in a better way. In any event, that the 3-way merge is really just a stupid 3-way merge (modulo multiple merge base madness) does seem worth emphasizing, so thanks for working on this. My goal is simply to stop having to answer the same question on the list twice within two weeks. :-) -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [RFC/PATCH] rebase: use reflog to find common base with upstream
On Sun, Dec 8, 2013 at 12:06 PM, John Keeping j...@keeping.me.uk wrote:
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream}'. That is also what
'git pull [--rebase]' defaults to, so it only makes sense that
'git rebase' defaults to the same thing.
but that isn't actually the case. Since commit d44e712 (pull: support
rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
chosen the most recent reflog entry which is an ancestor of the current
branch if it can find one.
In my mind, 'git pull --rebase' does default to @{u}, it just started
interpreting it differently in d44e712, but maybe I'm just being
defensive :-).
In a similar way, I think your patch is about interpreting the
upstream argument differently, not about changing the default upstream
argument. This is why I think git rebase and git rebase
origin/master should be the same (when origin/master is the
configured upstream).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-subtree manpage missing from git-manpages tarballs
Hi Jonathan, On Sun, Dec 8, 2013 at 5:30 PM, Jonathan Nieder jrnie...@gmail.com wrote: git-subtree and its documentation are in the contrib/subtree directory. contrib/subtree/Makefile includes rules to build a manpage for it. Thanks - I guess git-manpages generally doesn't include bits from contrib then. If the homebrew rules are installing the git-subtree command from there, perhaps they could be tweaked to build the manpage, too. What do you think? The homebrew recipe states: # We could build the manpages ourselves, but the build process depends # on many other packages, and is somewhat crazy, this way is easier. So while I'm sure it's possible it sounds like the current process is preferred. Alternatively: I'm not sure what the status of git-subtree maintenance is. Is there someone taking active enough care of it that it would make sense to promote it out of contrib/ to be a full git command installed by default? This would be most excellent; I'm only starting to use subtrees but after some painful experiences with submodules I really like the subtree model so far. Thanks, Stefanus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
A couple of rebase --autosquash proposals
Hi, I am using Git 1.8.4.3 compiled by me on OEL6. I'd like to be able to use rebase --autosquash like this: == # git log commit b94f970cd869dfbf5254b19867fa7200df732d4f Author: Me m...@me.com Date: Mon Dec 9 17:02:32 2013 -0800 fixup! This is a second fixup. commit 64e516c8b26b7e0531a1e8b2fc8dfa21de259b85 Author: Me m...@me.com Date: Sun Dec 8 17:02:32 2013 -0800 fixup! This is a meaningful commit-log message, on a new line, that will be discarded later during rebase --autosquash. commit f21cd48d5eeac92130dc0617252c6ee6989c0252 Author: Me m...@me.com Date: Tue Dec 3 21:47:52 2013 -0800 This is the commit that will be fixed-up. commit 259c0eb41ef16ac94868ee3c9253ba938ed24c9f Author: Me m...@me.com Date: Mon Dec 2 21:47:52 2013 -0800 This commit is origin/master. == then # git rebase -i --autosquash 259c0eb41ef16ac94868ee3c9253ba938ed24c9f The differences here are: * fixup! or squash! on it's own would default to fixing-up the previous commit (or result of previous step of rebase if that was a squash/fixup). Interestingly using HEAD~1 or HEAD^1 works, but it only works for a single fixup/squash. Is there another treeish that would work? * Allow real commit-log text, perhaps only on lines other than the first line (the one containing the fixup). The motivations are: * I can default a fixup to apply to the previous commit (a common wish) without explicitly stating it's treeish or commit-message. * I can easily apply multiple fixups. * I can retain a meaningful WIP commit-log prior to the rebase - I can still see what each commit does, without needing to forgo the future autosquash capability - just put the !fixup or !squash on the first line on its own, and put the real changes on line 2 and onwards. In the case of squash! instead of fixup!, this means I could retain some valuable text to be squashed into the original commit. Thoughts on these two ideas? Thanks Brett -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/10] t6050: add tests for listing with --format
On Sat, Dec 7, 2013 at 11:21 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This patch adds tests for git replace -l --format=fmt.
Only tests when fmt is 'medium' and 'full' are needed
because 'short' is the same as with no --format option.
Nevertheless, don't you want to test that it behaves in the expected
manner when given --format=short and other legal or illegal
combinations?
--format
--format short
--format bogus
...etc...
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 27 +++
1 file changed, 27 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index bb785ec..3627b4c 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -281,6 +281,33 @@ test_expect_success 'git cat-file --batch works on
replace objects' '
echo $PARA3 | git cat-file --batch
'
+test_expect_success 'test --format medium' '
+ H1=$(git --no-replace-objects rev-parse HEAD~1)
+ HT=$(git --no-replace-objects rev-parse HEAD^{tree})
+ MYTAG=$(git --no-replace-objects rev-parse mytag)
+ {
+ echo $H1 - $BLOB
+ echo $BLOB - $REPLACED
+ echo $HT - $H1
+ echo $PARA3 - $S
+ echo $MYTAG - $HASH1
+ } | sort expected
+ git replace -l --format medium | sort actual
+ test_cmp expected actual
+'
+
+test_expect_failure 'test --format full' '
+ {
+ echo $H1 (commit) - $BLOB (blob)
+ echo $BLOB (blob) - $REPLACED (blob)
+ echo $HT (tree) - $H1 (commit)
+ echo $PARA3 (commit) - $S (commit)
+ echo $MYTAG (tag) - $HASH1 (commit)
+ } | sort expected
+ git replace --format=full | sort actual
+ test_cmp expected actual
+'
+
test_expect_success 'replace ref cleanup' '
test -n $(git replace)
git replace -d $(git replace)
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/10] t6050: add tests for listing with --format
From: Eric Sunshine sunsh...@sunshineco.com On Sat, Dec 7, 2013 at 11:21 AM, Christian Couder chrisc...@tuxfamily.org wrote: This patch adds tests for git replace -l --format=fmt. Only tests when fmt is 'medium' and 'full' are needed because 'short' is the same as with no --format option. Nevertheless, don't you want to test that it behaves in the expected manner when given --format=short and other legal or illegal combinations? --format --format short --format bogus ...etc... Ok, I will add more tests. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A couple of rebase --autosquash proposals
Am 12/9/2013 3:23, schrieb Brett Randall: * fixup! or squash! on it's own would default to fixing-up the previous commit (or result of previous step of rebase if that was a squash/fixup). Why would you want that? To fixup the previous commit, just use 'git commit --amend'. What am I missing? -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
