Re: [PATCH 6/7] sha1_name: cleanup interpret_branch_name()
From: "Felipe Contreras"
The 'upstream' variable doesn't hold an "upstream", but a branch, so
make it clearer.
Signed-off-by: Felipe Contreras
---
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 writes: > Am 07.12.2013 23:23, schrieb Thomas Rast: >> Karsten Blees 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
---
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
---
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 "
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 --- 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 --- 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
---
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 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 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 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 Date: Mon Dec 9 17:02:32 2013 -0800 fixup! This is a second fixup. commit 64e516c8b26b7e0531a1e8b2fc8dfa21de259b85 Author: Me 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 Date: Tue Dec 3 21:47:52 2013 -0800 This is the commit that will be fixed-up. commit 259c0eb41ef16ac94868ee3c9253ba938ed24c9f Author: Me 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
wrote:
> This patch adds tests for "git replace -l --format=".
> Only tests when 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
> ---
> 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 > > On Sat, Dec 7, 2013 at 11:21 AM, Christian Couder > wrote: >> This patch adds tests for "git replace -l --format=". >> Only tests when 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
