Rename edge case...
I've been browsing StackOverflow answering git-related questions, and ran across this one: http://stackoverflow.com/questions/13300675/git-merge-rename-conflict It's a bit of an interesting situation. The user did a couple of renames in a branch: foo.txt = fooOld.txt fooNew.txt = foo.txt Meanwhile, master had an update to fooNew.txt. When the user tried to merge master to the branch, it gave a merge conflict saying fooNew.txt was deleted, but master tried to update it. I was a bit surprised that git didn't follow the rename here, though I do understand why: git only sees it as a rename if the source disappears completely. So I played locally with a few ideas, and was surprised to find out that even breaking up the two renames into two separate commits git still didn't follow it. I'm just curious--I don't run into this often myself--but is there a good strategy for dealing with this that avoids the conflict? Thanks! -John -- 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: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
Jeff King venit, vidit, dixit 08.11.2012 21:09: On Fri, Nov 02, 2012 at 03:43:24PM +0100, Michael J Gruber wrote: It seems that our fast-import is super picky with regards to author names. I've encountered author names like Foo Barfoo@dev.null Foo Bar foo@dev.null foo@dev.null in the self-hosting repo of some other dvcs, and the question is how to translate them faithfully into a git author name. It is not just fast-import. Git's author field looks like an rfc822 address, but it's much simpler. It fundamentally does not allow angle brackets in the name field, regardless of any quoting. As you noted in your followup, we strip them out if you provide them via GIT_AUTHOR_NAME. I doubt this will change anytime soon due to the compatibility fallout. So it is up to generators of fast-import streams to decide how to encode what they get from another system (you could come up with an encoding scheme that represents angle brackets). I don't expect our requirements to change. For one thing, I was surprised that git-commit is more tolerant than git-fast-import, but it makes a lot of sense to avoid any behind-the-back conversions in the importer. In general, we try to do fullotherdvcsname none@none if the other system's entry does not parse as a git author name, but fast-import does not accept either of Foo Barfoo@dev.null none@none Foo Barfoo@dev.null none@none because of the way it parses for . While the above could be easily turned into Foo Bar foo@dev.null it would not be a faithful representation of the original commit in the other dvcs. I'd think that if a remote system has names with angle brackets and email-looking things inside them, we would do better to stick them in the email field rather than putting in a useless none@none. The latter should only be used for systems that lack the information. But that is a quality-of-implementation issue for the import scripts (and they may even want to have options, just like git-cvsimport allows mapping cvs usernames into full identities). That was more my real concern. In our cvs and svn interfaces, we even encourage the use of author maps. For example, if you use an author map, git-svn errors out if it encounters an svn user name which is not in the map. On the other hand, we can map all (most?) svn user names faithfully without using a map (e.g. to username none@none). Hg seems to store just anything in the author field (committer). The various interfaces that are floating around do some behind-the-back conversion to git format. The more conversions they do, the better they seem to work (no erroring out) but I'm wondering whether it's really a good thing, or whether we should encourage a more diligent approach which requires a user to map non-conforming author names wilfully. Michael -- 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: Rename edge case...
On Fri, 09 Nov 2012 04:10:31 -0500, John Szakmeister j...@szakmeister.net wrote: I've been browsing StackOverflow answering git-related questions, and ran across this one: http://stackoverflow.com/questions/13300675/git-merge-rename-conflict It's a bit of an interesting situation. The user did a couple of renames in a branch: foo.txt = fooOld.txt fooNew.txt = foo.txt Meanwhile, master had an update to fooNew.txt. When the user tried to merge master to the branch, it gave a merge conflict saying fooNew.txt was deleted, but master tried to update it. I was a bit surprised that git didn't follow the rename here, though I do understand why: git only sees it as a rename if the source disappears completely. So I played locally with a few ideas, and was surprised to find out that even breaking up the two renames into two separate commits git still didn't follow it. I'm just curious--I don't run into this often myself--but is there a good strategy for dealing with this that avoids the conflict? When merging two branches, git only looks at the tips. It doesn't inspect their histories to see how the files were moved around. So i doesn't matter whether you rename the files in a single commit or multiple commits. The resulting tree is always the same. tom -- 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: Rename edge case...
On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: [snip] When merging two branches, git only looks at the tips. It doesn't inspect their histories to see how the files were moved around. So i doesn't matter whether you rename the files in a single commit or multiple commits. The resulting tree is always the same. I guess I figured that when I saw the final result, but didn't know if there was a way to coax Git into doing a better job here. I guess not though. At least it's a situation that doesn't come up often. -John -- 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: Rename edge case...
On Fri, Nov 9, 2012 at 5:25 PM, John Szakmeister j...@szakmeister.net wrote: On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: [snip] When merging two branches, git only looks at the tips. It doesn't inspect their histories to see how the files were moved around. So i doesn't matter whether you rename the files in a single commit or multiple commits. The resulting tree is always the same. I guess I figured that when I saw the final result, but didn't know if there was a way to coax Git into doing a better job here. I guess not though. There is not (yet). There were a few patches around that allow users to override git's automatic renames. You can search the mail archive. I think the keywords are rename cache. Thanks for reminding me for putting a higher priority on that. -- Duy -- 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] cache-tree: invalidate i-t-a paths after writing trees
Intent-to-add entries used to forbid writing trees so it was not a problem. After commit 3f6d56d (commit: ignore intent-to-add entries instead of refusing - 2012-02-07), an index with i-t-a entries can write trees. However, the commit forgets to invalidate all paths leading to i-t-a entries. With fully valid cache-tree (e.g. after commit or write-tree), diff operations may prefer cache-tree to index and not see i-t-a entries in the index, because cache-tree does not have them. The invalidation is done after calling update_one() in cache_tree_update() for simplicity because it's probably not worth the complexity of changing a recursive function and the performance bottleneck won't likely fall to this new loop, rather in write_sha1_file or hash_sha1_file. But this means that if update_one() has new call sites, they must re-do the same what this commit does to avoid the same fault. Reported-by: Jonathon Mah m...@jonathonmah.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- cache-tree.c | 3 +++ t/t2203-add-intent.sh | 20 2 files changed, 23 insertions(+) diff --git a/cache-tree.c b/cache-tree.c index 28ed657..30a8018 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it, i = update_one(it, cache, entries, , 0, flags); if (i 0) return i; + for (i = 0; i entries; i++) + if (cache[i]-ce_flags CE_INTENT_TO_ADD) + cache_tree_invalidate_path(it, cache[i]-name); return 0; } diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh index ec35409..2a4a749 100755 --- a/t/t2203-add-intent.sh +++ b/t/t2203-add-intent.sh @@ -62,5 +62,25 @@ test_expect_success 'can commit -a with an i-t-a entry' ' git commit -a -m all ' +test_expect_success 'cache-tree invalidates i-t-a paths' ' + git reset --hard + mkdir dir + : dir/foo + git add dir/foo + git commit -m foo + + : dir/bar + git add -N dir/bar + git diff --cached --name-only actual + echo dir/bar expect + test_cmp expect actual + + git write-tree /dev/null + + git diff --cached --name-only actual + echo dir/bar expect + test_cmp expect actual +' + test_done -- 1.8.0.rc2.23.g1fb49df -- 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] cache-tree: invalidate i-t-a paths after writing trees
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: diff --git a/cache-tree.c b/cache-tree.c index 28ed657..30a8018 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it, i = update_one(it, cache, entries, , 0, flags); if (i 0) return i; + for (i = 0; i entries; i++) + if (cache[i]-ce_flags CE_INTENT_TO_ADD) + cache_tree_invalidate_path(it, cache[i]-name); return 0; } I notice there is another special case for CE_REMOVE but there is nothing that adjusts the cache-tree for these entries in the current codebase. I suspect the original code before we (perhaps incorrectly) updated the code not to error out upon I-T-A entries was fine only because we do not attempt to fully populate the cache-tree during a merge in the unpack-trees codepath, which will mark the index entries that are to be removed with CE_REMOVE in the resulting index. The solution implemented with this patch will break if we start updating the cache tree after a successful merge in unpack-trees, I suspect. An alternative might be to add a phoney bit next to used in the cache_tree structure, mark the cache tree as phoney when we skip an entry marked as CE_REMOVE or CE_ITA, and make the postprocessing loop this patch adds aware of that bit, instead of iterating over the index entries; instead, it would recurse the resulting cache tree and invalidate parts of the tree that have subtrees with the phoney bit set, or something. -- 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: Rename edge case...
Am 11/9/2012 11:25, schrieb John Szakmeister: On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: [snip] When merging two branches, git only looks at the tips. It doesn't inspect their histories to see how the files were moved around. So i doesn't matter whether you rename the files in a single commit or multiple commits. The resulting tree is always the same. I guess I figured that when I saw the final result, but didn't know if there was a way to coax Git into doing a better job here. If the renames are split in two commits, you can merge the first, and then the second on top of the result. -- 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
bash completion of addable files for `git add`
hi,
i've always been annoyed by having to type — or copy paste — paths when i
wanted to simply add some files to the index. i know about the `add -i`
interface, and that improves things a little, but having bash completion for so
many other things it still seemed to much hassle.
so here's a patch adding bash completion on `git add` for modified, updated and
untracked files. i've also set up a pull request — before i found
`Documentation/SubmittingPatches`. fwiw, it's at
https://github.com/git/git/pull/29
best regards,
andi
From cbac6caee7e788569562cb7138eb698cc46a1b8f Mon Sep 17 00:00:00 2001
From: Andreas Zeidler a...@zitc.de
Date: Fri, 9 Nov 2012 13:05:43 +0100
Subject: [PATCH] add bash completion for addable files
this adds support for completing only modified, updated and untracked
files on `git add`, since almost always these are what you want to add
to the index.
the list of possible completions is determined using `git status` and
filtered using `egrep` and `sed`.
Signed-off-by: Andreas Zeidler a...@zitc.de
---
contrib/completion/git-completion.bash | 15 +++
t/t9902-completion.sh | 11 +++
2 files changed, 26 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..4aa0981 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -799,6 +799,16 @@ _git_apply ()
COMPREPLY=()
}
+__git_addable ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir status --short --untracked=all |\
+ egrep '^.[UM?] ' | sed 's/^.. //'
+ return
+ fi
+}
+
_git_add ()
{
__git_has_doubledash return
@@ -810,6 +820,11 @@ _git_add ()
--ignore-errors --intent-to-add
return
+ ;;
+ *)
+ __gitcomp $(__git_addable)
+ return
+ ;;
esac
COMPREPLY=()
}
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index cbd0fb6..a7c81d3 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -288,4 +288,15 @@ test_expect_failure 'complete tree filename with
metacharacters' '
EOF
'
+test_expect_success 'add completes untracked and modified names' '
+ echo other content file1
+ echo content file2
+ echo more file3
+ git add file1
+ test_completion_long git add f -\EOF
+ file2_
+ file3_
+ EOF
+'
+
test_done
--
1.8.0.1.g43af610
--
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
upgrade to plone 4! -- http://plone.org/4
--
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 svn problem, probably a regression
Use of uninitialized value $u in substitution (s///) at /usr/local/Cellar/git/1.8.0/lib/Git/SVN.pm line 106. Use of uninitialized value $u in concatenation (.) or string at /usr/local/Cellar/git/1.8.0/lib/Git/SVN.pm line 106. refs/remotes/svn/asset-manager-redesign: 'svn+ssh://IP address' not found in '' If you have time and can reproduce the bug at will, it would be very helpful to use git-bisect to pinpoint the exact commit that causes the breakage. -Peff I just encountered the exact same issue while converting an svn repo to git on Windows through Git Bash. Same error. -- 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: Everybody,Attention !!!
Gee. How cleaver. A spam email outing a spam web site. IMNSHO, anybody who doesn't use their real name is most likely a troll or spammer. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of uncle2me Sent: Friday, November 09, 2012 12:43 AM To: git@vger.kernel.org Subject: Everybody,Attention !!! http://www.airmax95sgr.com/ it is spam site.Fake and shoddy products.I hope you do not be fooled.Good luck to you -- View this message in context: http://git.661346.n2.nabble.com/Everybody-Attention-tp7570724.html Sent from the git mailing list archive at Nabble.com. -- 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
git merge commits are non-deterministic? what changed?
Hi all, I'm running a couple of conversions from SVN to git, using a slightly hacked version of svn2git (because it can cope with multiple branches and is several orders of magnitude faster than git-svn). Anyway, when doing some verification runs, using the same version of svn2git, but different versions of git, I get different commit hashes, and I tracked it down to the ordering of the parents inside a merge commit. version 1.7.9.2 % git show --format=raw e209a83|head commit e209a83c1e0a387c88a44f3a8f2be2670ed85eae tree de2d7c6726a45428d4a310da2acd8839daf9f85f parent 5fba0401c23a594e4ad5e807bf14a5439645a358 parent 25062ba061871945759b3baa833fe64969383e40 parent 89bebeef185ed08424fc548f8569081c6add2439 parent c7d5f60d3a7e2e3c4da23b157c62504667344438 parent e7bc108f0d6a394050818a4af64a59094d3c793e parent 48231afadc40013e6bfda56b04a11ee3a602598f author rgrimes rgri...@freebsd.org 739897097 + committer rgrimes rgri...@freebsd.org 739897097 + vs git version 1.8.0 % git show --format=raw 42f0fad|head commit 42f0fadccab6eefc7ffdc1012345b42ad45e36c2 tree de2d7c6726a45428d4a310da2acd8839daf9f85f parent 5fba0401c23a594e4ad5e807bf14a5439645a358 parent 25062ba061871945759b3baa833fe64969383e40 parent 89bebeef185ed08424fc548f8569081c6add2439 parent 48231afadc40013e6bfda56b04a11ee3a602598f parent c7d5f60d3a7e2e3c4da23b157c62504667344438 parent e7bc108f0d6a394050818a4af64a59094d3c793e author rgrimes rgri...@freebsd.org 739897097 + committer rgrimes rgri...@freebsd.org 739897097 + I haven't verified to see if that ordering is stable within a git version, but the fact that it changed across versions clearly means that I cannot depend on this currently (I have never seen this problem in two years, so I blame git 1.8.0 ...) Two questions: 1. Can we impose a stable ordering of the commits being recorded in a merge commit? Listing parents in chronological order or something like that. 2. Why the hell is the commit hash dependent on the ordering of the parent commits? IMHO it should sort the set of parents before calculating the hash ... Help? Uli -- 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: Revert option for git add --patch
Jonathon Mah jmah at me.com writes: Nathan, I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p). Other front-ends like Egg and Magit has been providing the ability to move hunks back and forth, for a long time. -- 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 merge commits are non-deterministic? what changed?
Ulrich Spörlein u...@spoerlein.net writes: Two questions: 1. Can we impose a stable ordering of the commits being recorded in a merge commit? Listing parents in chronological order or something like that. The order is determined by the order the refs are given to git merge (or git commit-tree when using the plumbing). 2. Why the hell is the commit hash dependent on the ordering of the parent commits? IMHO it should sort the set of parents before calculating the hash ... What would be the sort key? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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 merge commits are non-deterministic? what changed?
On Fri, 2012-11-09 at 16:04:31 +0100, Andreas Schwab wrote: Ulrich Spörlein u...@spoerlein.net writes: Two questions: 1. Can we impose a stable ordering of the commits being recorded in a merge commit? Listing parents in chronological order or something like that. The order is determined by the order the refs are given to git merge (or git commit-tree when using the plumbing). 2. Why the hell is the commit hash dependent on the ordering of the parent commits? IMHO it should sort the set of parents before calculating the hash ... What would be the sort key? Trivially, the hash of the parents itself. So you'd always get ... parent parent parent parent hth Uli -- 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 merge commits are non-deterministic? what changed?
Ulrich Spörlein u...@spoerlein.net writes: 2. Why the hell is the commit hash dependent on the ordering of the parent commits? IMHO it should sort the set of parents before calculating the hash ... What would be the sort key? Trivially, the hash of the parents itself. So you'd always get ... parent parent parent parent That would change the behavior of --first-parent. Or you'd need to compute the sha1 of the sorted list, but keep the unsorted one in the commit. Possible, but weird ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: Rename edge case...
On Fri, Nov 09, 2012 at 04:10:31AM -0500, John Szakmeister wrote: I've been browsing StackOverflow answering git-related questions, and ran across this one: http://stackoverflow.com/questions/13300675/git-merge-rename-conflict It's a bit of an interesting situation. The user did a couple of renames in a branch: foo.txt = fooOld.txt fooNew.txt = foo.txt Meanwhile, master had an update to fooNew.txt. When the user tried to merge master to the branch, it gave a merge conflict saying fooNew.txt was deleted, but master tried to update it. I was a bit surprised that git didn't follow the rename here, though I do understand why: git only sees it as a rename if the source disappears completely. Right. If the source didn't go away, it would be a copy. We can do copy detection, but it is not quite as obvious what a merge should do with a copy (apply the change to the original? To the copy? In both places? You would really want hunk-level copy detection for it to make any sense). Usually git deals with this double-rename case through the use of break or rewrite detection. We notice that the old foo.txt and the new foo.txt do not look very much like each other, and break the modification apart into an add and a delete. That makes each side eligible for rename detection, and we can end up finding the pairs of renames above. So in theory it just as simple as a one-liner to turn on break-detection in merge-recursive. Sadly, that only reveals more issues with how merge-recursive handles renames. See this thread, which has pointers to the breakages at the end: http://thread.gmane.org/gmane.comp.version-control.git/169944 I've become convinced that the best way forward with merge-recursive is to scrap and rewrite it. It tries to do things in a muddled order, which makes it very brittle to changes like this. I think it needs to have an internal representation of the tree that can represent all of the conflicts, and then follow a few simple phases: 1. structural 3-way merge handling renames, breaks, typechanges, etc. Each path in tree might show things like D/F conflicts, or it might show content-level merges that still need to happen, even if the content from those merges is not coming from the same paths in the source trees. 2. Resolve content-level 3-way merges at each path. 3. Compare the proposed tree to the working tree and list any problems (e.g., untracked files or local modifications that will be overwritten). Right now it tries to do these things interleaved as it processes paths, and as a result we've had many bugs (e.g., the content-level merge conflating the content originally at a path and something that was renamed into place, and missing corner cases where we actually overwrite untracked files that should be considered precious). But that is just off the top of my head. I haven't looked at the topic in quite a while (and I haven't even started working on any such rewrite). So I played locally with a few ideas, and was surprised to find out that even breaking up the two renames into two separate commits git still didn't follow it. Right, because the merge only looks at the end points. Try doing a diff -M between your endpoints with and without -B. We do not have any double-renames in git.git, but you can find -B helping a similar case: most of a file's content is moved elsewhere, but some small amount remains. For example, try this in git.git, with and without -B: git show -M --stat --summary --patch 043a449 It finds the rename only with -B, which would help a merge (it also makes the diff shorter and more readable, as you can see what was changed as the content migrated to the new file). -Peff -- 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 merge commits are non-deterministic? what changed?
On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote: Ulrich Spörlein u...@spoerlein.net writes: 2. Why the hell is the commit hash dependent on the ordering of the parent commits? IMHO it should sort the set of parents before calculating the hash ... What would be the sort key? Trivially, the hash of the parents itself. So you'd always get ... parent parent parent parent That would change the behavior of --first-parent. Or you'd need to compute the sha1 of the sorted list, but keep the unsorted one in the commit. Possible, but weird ;-). Right. The reason that merge parents are stored in the order given on the command line is not random or because it was not considered. It encodes a valuable piece of information: did the user merge foo into bar, or did they merge bar into foo? So I think this discussion is going in the wrong direction; git should never sort the parents, because the order is meaningful. The original complaint was that a run of svn2git produced different results on two different git versions. The important question to me is: did svn2git feed the parents to git in the same order? If it did, and git produced different results, then that is a serious bug. If it did not, then the issue needs to be resolved in svn2git (which _may_ want to sort the parents that it feeds to git, but it would depend on whether the order it is currently presenting is meaningful). -Peff -- 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: bash completion of addable files for `git add`
On Fri, Nov 09, 2012 at 02:22:27PM +0100, Andreas Zeidler wrote:
so here's a patch adding bash completion on `git add` for modified,
updated and untracked files. i've also set up a pull request — before
i found `Documentation/SubmittingPatches`. fwiw, it's at
https://github.com/git/git/pull/29
Please put cover letter material like this after the --- divider, or
include a -- 8 -- scissors line before your commit. Either helps git
am realize which content should go into the commit message.
From cbac6caee7e788569562cb7138eb698cc46a1b8f Mon Sep 17 00:00:00 2001
From: Andreas Zeidler a...@zitc.de
Date: Fri, 9 Nov 2012 13:05:43 +0100
Please omit these lines, as they are redundant with your email header.
Subject: [PATCH] add bash completion for addable files
This one is useful, but it would be even better if it were the subject
of your email. :)
+__git_addable ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir status --short --untracked=all |\
+ egrep '^.[UM?] ' | sed 's/^.. //'
+ return
+ fi
+}
You would want to use the stable, scriptable --porcelain output, so
the completion is not broken by future changes to the --short format.
However, I do not think using git status is the best option. It
computes three things:
1. The diff between HEAD and index.
2. The diff between index and working tree.
3. The list of untracked files.
But you only care about (2) and (3), so you are wasting time computing
(1). I think the list you want could be generated with:
git diff-files --name-only
git ls-files --exclude-standard -o
and then you do not need to worry about grep or sed at all.
@@ -810,6 +820,11 @@ _git_add ()
--ignore-errors --intent-to-add
return
+ ;;
+ *)
+ __gitcomp $(__git_addable)
+ return
+ ;;
I think you'd want to use __gitcomp_nl to handle filenames with spaces.
Speaking of which, the output of status (or of the commands I mentioned)
may have quoting applied to pathnames. I think that is not something we
handle very well right now in the completion, so it may not be worth
worrying about for this particular patch.
Other than those comments, I think the intent of your patch makes a lot
of sense.
-Peff
--
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 v3 1/3] git-submodule add: Add -r/--record option
Hi, On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: By remaining agnostic on the variable usage, this patch makes submodule setup more convenient for all parties. I personally do not think remaining agnostic on the usage is a good thing, at least for any option to commands at the higher level on the stack, such as git submodule. I am afraid that giving an easier way to set up a variable with undefined semantics may make setup more confusing for all parties. One party gives one specific meaning to the field, while another party uses it for something slightly different. I would not object to git config submodule.$name.branch $value, on the other hand. git config can be used to set a piece of data that has specific meaning, but as a low-level tool, it is not _limited_ to variables that have defined meaning. I think we should agree on a behavior for this option and implement it the same time when add learns about it. When we were discussing floating submodules as an important option for the gerrit people I already started to implement a proof of concept. Please have a look here: https://github.com/hvoigt/git/commits/hv/floating_submodules AFAIK this does not yet implement the same behaviour the gerrit tools offer for this option. The main reason behind that was because I do not know the typical workflow behind such an option. So I am open to changes. Maybe you can use or base your work on this implementation for submodule update. Without submodule update using this option I think it would be better to implement this option in the tool you are using instead of submodule add. Everything else feels incomplete to me. Cheers Heiko -- 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-clone and unreliable links?
On Wed, Nov 7, 2012 at 9:24 PM, Shawn Pearce spea...@spearce.org wrote: On Wed, Nov 7, 2012 at 7:35 AM, Josef Wolf j...@raven.inka.de wrote: When using git-clone over an unreliable link (say, UMTS) and the network goes down, git-clone deletes everything what was downloaded. When the network goes up again and you restart git-clone, it has to start over from the beginning. Then, eventually, the network goes down again, and everything is deleted again. Is there a way to omit the deleting step, so the second invocation would start where the first invocation was interrupted? No, because a clone is not resumable. The best way to obtain a repository over an unstable link is to ask the repository owner to make a bundle file with `git bundle create --heads --tags` and serve the file using standard HTTP or rsync, which are resumable protocols. After you download the file, you can clone or fetch from the bundle to initialize your local repository, and then run git fetch to incrementally update to anything that is more recent than the bundle's creation. If the server is running gitolite, the admin can set it up so that a bundle file is automatically created as needed (including don't do it more than once per duration logic), and serve it up over rsync using the same ssh credentials as for access to the repo itself. However, this is not particularly useful for systems with git://, although it could certainly be *adapted* for http access. [Documentation is inline, in src/commands/rsync, for people who wish to know.] -- Sitaram -- 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] gitweb: make remote_heads config setting work.
On Thu, Nov 08, 2012 at 08:40:11PM -0800, Junio C Hamano wrote:
Looking at the code before this part:
if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
$key = join(., lc($hi), $mi, lc($lo));
} else {
$key = lc($key);
}
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
the new code is munding the $hi and $mi parts, while the mistaken
configuration this patch is trying to correct is about the $lo part,
and possibly the $hi part, but never the $mi part.
Good catch. I think the return in the existing code suffers from the
same problem: it will bail on non-word characters in the $mi part, but
that part should allow arbitrary characters.
-Peff
--
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 v3 2/3] git-submodule foreach: export .gitmodules settings as variables
Hi,
On Thu, Nov 08, 2012 at 10:35:13PM -0500, W. Trevor King wrote:
From: W. Trevor King wk...@tremily.us
This makes it easy to access per-submodule variables. For example,
git submodule foreach 'git checkout $(git config --file
$toplevel/.gitmodules submodule.$name.branch) git pull'
can now be reduced to
git submodule foreach 'git checkout $submodule_branch git pull'
What other use cases are there? Would the need for this maybe go away
once you had floating submodules following branches?
The whole thing looks like its adding some complex code which is not so
easy to read. I would like to make sure its worth it.
diff --git a/git-submodule.sh b/git-submodule.sh
index bc33112..e4d26f9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -434,8 +434,24 @@ cmd_foreach()
clear_local_git_env
# we make $path available to scripts ...
path=$sm_path
+
+ # make all submodule variables available to
scripts
+ eval $(
+ git config -f .gitmodules --get-regexp
^submodule\.${name}\..* |
For completeness you should make the variables possible to override by
repository from the local repository configuration like all other
submodule options that are read directly from .gitmodules.
Cheers Heiko
--
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: [PATCHv2] replace: parse revision argument for -d
On Mon, Oct 29, 2012 at 02:23:27PM +0100, Michael J Gruber wrote:
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the arguments to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
v2 has the simplified error check as per Jeff, and a reworded message.
Comes with a free test case, too.
I noticed this today in my pile of to look at patches. Sorry for being
slow.
for (p = argv; *p; p++) {
- if (snprintf(ref, sizeof(ref), refs/replace/%s, *p)
- = sizeof(ref)) {
- error(replace ref name too long: %.*s..., 50, *p);
+ q = *p;
+ if (get_sha1(q, sha1)) {
+ error(Failed to resolve '%s' as a valid ref., q);
had_error = 1;
continue;
}
Looks reasonable.
+ q = sha1_to_hex(sha1);
+ snprintf(ref, sizeof(ref), refs/replace/%s, q);
if (read_ref(ref, sha1)) {
- error(replace ref '%s' not found., *p);
+ error(replace ref '%s' not found., q);
I worry a little about assuming that q, which points to a static
internal buffer of sha1_to_hex, is still valid after calling read_ref.
We'll end up in resolve_ref, which might need to do considerable work
(e.g., loading the whole packed refs file). Just grepping for
sha1_to_hex, I don't think it is a problem currently, but it might be
worth copying the value (you could even point into the ref buffer to
avoid dealing with an extra allocation).
Other than that, it looks good to me.
-Peff
--
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 merge commits are non-deterministic? what changed?
On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote: On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote: Ulrich Spörlein u...@spoerlein.net writes: 2. Why the hell is the commit hash dependent on the ordering of the parent commits? IMHO it should sort the set of parents before calculating the hash ... What would be the sort key? Trivially, the hash of the parents itself. So you'd always get ... parent parent parent parent That would change the behavior of --first-parent. Or you'd need to compute the sha1 of the sorted list, but keep the unsorted one in the commit. Possible, but weird ;-). Right. The reason that merge parents are stored in the order given on the command line is not random or because it was not considered. It encodes a valuable piece of information: did the user merge foo into bar, or did they merge bar into foo? So I think this discussion is going in the wrong direction; git should never sort the parents, because the order is meaningful. The original complaint was that a run of svn2git produced different results on two different git versions. The important question to me is: did svn2git feed the parents to git in the same order? If it did, and git produced different results, then that is a serious bug. If it did not, then the issue needs to be resolved in svn2git (which _may_ want to sort the parents that it feeds to git, but it would depend on whether the order it is currently presenting is meaningful). Yeah, thanks, looks like I have some more work to do. I don't quite get how it could come up with a different order, seeing that it is using svn as the base. Will run some more experiments, thanks for the info so far. Cheers, Uli -- 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 1/5] push: return reject reasons via a mask
On Sun, Nov 04, 2012 at 09:08:24PM -0600, Chris Rorvick wrote: Pass all rejection reasons back from transport_push(). The logic is simpler and more flexible with regard to providing useful feedback. [...] void transport_print_push_status(const char *dest, struct ref *refs, - int verbose, int porcelain, int *nonfastforward); + int verbose, int porcelain, unsigned int *reject_mask); You missed updating one call-site of this function in builtin/send-pack.c (gcc -Wall will now complain of the signed/unsigned mismatch in the passed-in pointer). -Peff -- 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 0/5] push: update remote tags only with force
On Sun, Nov 04, 2012 at 09:08:23PM -0600, Chris Rorvick wrote: Patch series to prevent push from updating remote tags w/o forcing them. Split out original patch to ease review. Chris Rorvick (5): push: return reject reasons via a mask push: add advice for rejected tag reference push: flag updates push: flag updates that require force push: update remote tags only with force Documentation/git-push.txt | 10 +- builtin/push.c | 24 +++- builtin/send-pack.c|6 ++ cache.h|7 ++- remote.c | 39 +++ t/t5516-fetch-push.sh | 30 +- transport-helper.c |6 ++ transport.c| 25 +++-- transport.h| 10 ++ 9 files changed, 119 insertions(+), 38 deletions(-) I have not looked carefully at this topic yet, but I did try merging it to pu and found that it had some textual conflicts with the nd/builtin-to-libgit topic, which moves some builtin/send-pack.c code to send-pack.c. Since I am graduating that topic to master, I went ahead and just rebased your topic on top. If you do a re-roll, please use an updated master, and feel free to grab (and double-check!) the rebase I am about to send out in 'pu'. I also included the minor signed/unsigned pointer warning fixup in the rebase, too. -Peff -- 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
[PATCHv3 1/4] Refactor print_state into get_state
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is useful to other callers who do
not want it printed in the same way.
Split the new print_state function into separate get_state and
print_state functions so others can get this state info and
share common code.
Signed-off-by: Phil Hord ho...@cisco.com
---
wt-status.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..760f52b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -928,34 +928,41 @@ static void show_bisect_in_progress(struct wt_status *s,
wt_status_print_trailer(s);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_get_state(struct wt_status *s , struct wt_status_state
*state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
struct stat st;
- memset(state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
+ /* Determine sequencer activity */
if (!stat(git_path(MERGE_HEAD), st)) {
- state.merge_in_progress = 1;
+ state-merge_in_progress = 1;
} else if (!stat(git_path(rebase-apply), st)) {
if (!stat(git_path(rebase-apply/applying), st)) {
- state.am_in_progress = 1;
+ state-am_in_progress = 1;
if (!stat(git_path(rebase-apply/patch), st)
!st.st_size)
- state.am_empty_patch = 1;
+ state-am_empty_patch = 1;
} else {
- state.rebase_in_progress = 1;
+ state-rebase_in_progress = 1;
}
} else if (!stat(git_path(rebase-merge), st)) {
if (!stat(git_path(rebase-merge/interactive), st))
- state.rebase_interactive_in_progress = 1;
+ state-rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
+ state-rebase_in_progress = 1;
} else if (!stat(git_path(CHERRY_PICK_HEAD), st)) {
- state.cherry_pick_in_progress = 1;
+ state-cherry_pick_in_progress = 1;
}
if (!stat(git_path(BISECT_LOG), st))
- state.bisect_in_progress = 1;
+ state-bisect_in_progress = 1;
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(s, state);
if (state.merge_in_progress)
show_merge_in_progress(s, state, state_color);
--
1.8.0.3.gde9c7d5.dirty
--
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
[PATCHv3 2/4] wt-status: Teach sequencer advice to use get_state
wt_status_print_state retrieves some sequencer state information via
wt_status_get_state, but other state information it deduces on its
own. Replace these local knowledge deductions with wt_status
variables so we can share more common code in the future.
---
wt-status.c | 16 +---
wt-status.h | 3 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 760f52b..a888120 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -781,7 +781,7 @@ static void show_merge_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- if (has_unmerged(s)) {
+ if (state-has_unmerged) {
status_printf_ln(s, color, _(You have unmerged paths.));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -867,9 +867,7 @@ static void show_rebase_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- struct stat st;
-
- if (has_unmerged(s)) {
+ if (state-has_unmerged) {
status_printf_ln(s, color, _(You are currently rebasing.));
if (advice_status_hints) {
status_printf_ln(s, color,
@@ -879,12 +877,12 @@ static void show_rebase_in_progress(struct wt_status *s,
status_printf_ln(s, color,
_( (use \git rebase --abort\ to check out
the original branch)));
}
- } else if (state-rebase_in_progress || !stat(git_path(MERGE_MSG),
st)) {
+ } else if (state-rebase_in_progress || state-commit_is_pending) {
status_printf_ln(s, color, _(You are currently rebasing.));
if (advice_status_hints)
status_printf_ln(s, color,
_( (all conflicts fixed: run \git rebase
--continue\)));
- } else if (split_commit_in_progress(s)) {
+ } else if (state-split_in_progress) {
status_printf_ln(s, color, _(You are currently splitting a
commit during a rebase.));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -907,7 +905,7 @@ static void show_cherry_pick_in_progress(struct wt_status
*s,
{
status_printf_ln(s, color, _(You are currently cherry-picking.));
if (advice_status_hints) {
- if (has_unmerged(s))
+ if (state-has_unmerged)
status_printf_ln(s, color,
_( (fix conflicts and run \git commit\)));
else
@@ -955,6 +953,10 @@ static void wt_status_get_state(struct wt_status *s ,
struct wt_status_state *st
}
if (!stat(git_path(BISECT_LOG), st))
state-bisect_in_progress = 1;
+
+ state-has_unmerged = has_unmerged(s);
+ state-split_in_progress = split_commit_in_progress(s);
+ state-commit_is_pending = !stat(git_path(MERGE_MSG), st);
}
static void wt_status_print_state(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 236b41f..0b866a2 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,6 +79,9 @@ struct wt_status_state {
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ int split_in_progress;
+ int has_unmerged;
+ int commit_is_pending;
};
void wt_status_prepare(struct wt_status *s);
--
1.8.0.3.gde9c7d5.dirty
--
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
[PATCHv3 3/4] git-status: show short sequencer state
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Sequencer state info tokens are displayed in short
form. 'git status --short -S' will show the normal short
status including the sequencer tokens. 'git status -S'
without --short will show only the new sequencer information
tokens in whatever the requested format is.
State token strings which may be emitted and their meanings:
merge a merge is in progress
am an am is in progress
am-is-emptythe am patch is empty
rebase a rebase is in progress
rebase-interactive an interactive rebase is in progress
cherry-picka cherry-pick is in progress
bisect a bisect is in progress
conflicted there are unresolved conflicts
commit-pending a commit operation is waiting to be completed
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
changed-index Changes exist in the index
changed-files Changes exist in the working directory
untracked New files exist in the working directory
Signed-off-by: Phil Hord ho...@cisco.com
---
Documentation/git-status.txt | 20
builtin/commit.c | 14 ++
wt-status.c | 34 ++
wt-status.h | 7 +++
4 files changed, 75 insertions(+)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..bdacf08 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,26 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more words
+ describing the state of the git sequencer. If --short is also
+ given, the words are shown at the beginning of the short-format
+ display after the one-line branch information, if present. If
+ --short is not given, then only the sequencer words are shown
+ with no other status information.
++
+ merge a merge is in progress
+ am an am is in progress
+ am-is-emptythe am patch is empty
+ rebase a rebase is in progress
+ rebase-interactive an interactive rebase is in progress
+ cherry-picka cherry-pick is in progress
+ bisect a bisect is in progress
+ conflicted there are unresolved conflicts
+ commit-pending a commit operation is waiting to be completed
+ splitting interactive rebase, commit is being split
+
-u[mode]::
--untracked-files[=mode]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..bf16cc6 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1060,6 +1060,11 @@ static int parse_and_validate_options(int argc, const
char *argv[],
if (s-null_termination status_format == STATUS_FORMAT_LONG)
status_format = STATUS_FORMAT_PORCELAIN;
+ if (s-show_sequencer status_format != STATUS_FORMAT_SHORT) {
+ s-show_sequencer = SHOW_SEQUENCER_ONLY;
+ if (status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_SHORT;
+ }
if (status_format != STATUS_FORMAT_LONG)
dry_run = 1;
@@ -1156,6 +1161,8 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
N_(show status concisely), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', branch, s.show_branch,
N_(show branch information)),
+ OPT_SET_INT('S', sequencer, s.show_sequencer,
+ N_(show sequencer state information),
SHOW_SEQUENCER_YES),
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
@@ -1188,6 +1195,11 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
if (s.null_termination status_format == STATUS_FORMAT_LONG)
status_format = STATUS_FORMAT_PORCELAIN;
+ if (s.show_sequencer status_format != STATUS_FORMAT_SHORT) {
+ s.show_sequencer = SHOW_SEQUENCER_ONLY;
+ if (status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_SHORT;
+ }
handle_untracked_files_arg(s);
if (show_ignored_in_status)
@@ -1384,6 +1396,8 @@ int cmd_commit(int argc, const char **argv, const char
What's cooking in git.git (Nov 2012, #02; Fri, 9)
What's cooking in git.git (Nov 2012, #02; Fri, 9) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The fourth batch of topics has graduated to master. This should be my last integration cycle, as Junio will be back to take over before the next one. You can find the changes described here in the integration branches of my repository at: git://github.com/peff/git.git Until Junio returns, kernel.org and the other usual places will not be updated. -- [New Topics] * cr/push-force-tag-update (2012-11-09) 5 commits - push: update remote tags only with force - push: flag updates that require force - push: flag updates - push: add advice for rejected tag reference - push: return reject reasons via a mask Require -f for push to update a tag, even if it is a fast-forward. Needs review. I'm undecided yet on whether the goal is the right thing to do, but it does prevent some potential mistakes. I haven't looked closely at the implementation itself; review from interested parties would be helpful. * fc/fast-export-fixes (2012-11-08) 14 commits - fast-export: don't handle uninteresting refs - fast-export: make sure updated refs get updated - fast-export: fix comparison in tests - fast-export: trivial cleanup - remote-testgit: make clear the 'done' feature - remote-testgit: report success after an import - remote-testgit: exercise more features - remote-testgit: cleanup tests - remote-testgit: remove irrelevant test - remote-testgit: get rid of non-local functionality - Add new simplified git-remote-testgit - Rename git-remote-testgit to git-remote-testpy - remote-testgit: fix direction of marks - fast-export: avoid importing blob marks Improvements to fix fast-export bugs, including how refs pointing to already-seen commits are handled. An earlier 4-commit version of this series looked good to me, but this much-expanded version has not seen any comments. Needs review. * mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit - push/pull: adjust missing upstream help text to changed interface Follow-on to the new --set-upstream-to topic from v1.8.0 to avoid suggesting the deprecated --set-upstream. Will merge to 'next'. * mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits - link_alt_odb_entries(): take (char *, len) rather than two pointers - link_alt_odb_entries(): use string_list_split_in_place() Cleanups in the alternates code. Fixes a potential bug and makes the code much cleaner. Will merge to 'next'. * pf/editor-ignore-sigint (2012-11-08) 1 commit - launch_editor: ignore SIGINT while the editor has control Avoid confusing cases where the user hits Ctrl-C while in the editor session, not realizing git will receive the signal. Since most editors will take over the terminal and will block SIGINT, this is not likely to confuse anyone. Comments welcome from people using unusual editors (e.g., a script that starts an editor in another window then blocks, waiting for the user to finish). * pp/gitweb-config-underscore (2012-11-08) 1 commit - gitweb: make remote_heads config setting work The key gitweb.remote_heads is not legal git config; this maps it to gitweb.remoteheads. Junio raised a good point about the implementation for three-level variables. Expecting a re-roll. * pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit - git p4: RCS expansion should not span newlines I do not have p4 to play with, but looks obviously correct to me. Will merge to 'next'. * rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit - gitweb.perl: fix %highlight_ext mappings Fixes a clever misuse of perl's list interpretation. Will merge to 'next'. * rr/submodule-diff-config (2012-11-08) 3 commits - submodule: display summary header in bold - diff: introduce diff.submodule configuration variable - Documentation: move diff.wordRegex from config.txt to diff-config.txt Lets git diff --submodule=log become the default via configuration. Seems like a good direction, though I had a few comments. Expecting a re-roll. -- [Graduated to master] * fc/completion-send-email-with-format-patch (2012-10-16) 1 commit (merged to 'next' on 2012-11-04 at 0a6366e) + completion: add format-patch options to send-email Will merge to 'master' in the fourth batch. * js/format-2047 (2012-10-18) 7 commits (merged to 'next' on 2012-10-25 at 76d91fe) + format-patch tests: check quoting/encoding in To: and Cc: headers + format-patch: fix rfc2047 address encoding with respect to rfc822 specials + format-patch: make rfc2047 encoding more strict + format-patch: introduce helper function last_line_length() + format-patch: do not wrap rfc2047 encoded headers too late + format-patch: do not wrap
Re: orphan blob or what?
Tomas Carnecky tomas.carne...@gmail.com writes: Just idiocy on my part. Thanks. On Thu, 08 Nov 2012 16:24:36 -0800, bruce bruce.e.robert...@intel.com wrote: In today's and older clones of https://github.com/mirrors/linux.git I find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it, can't see it via 'git log'. And yet linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile, 2010-09-29) references this blob. -- 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 (Nov 2012, #02; Fri, 9)
On Fri, Nov 9, 2012 at 8:23 PM, Jeff King p...@peff.net wrote: You can find the changes described here in the integration branches of my repository at: git://github.com/peff/git.git It seems that the repo doesn't contain the integration branches?!? $ git remote add peff git://github.com/peff/git.git $ git fetch -v peff From git://github.com/peff/git * [new branch] maint - peff/maint * [new branch] master - peff/master * [new branch] next - peff/next * [new branch] pu - peff/pu * [new branch] todo - peff/todo $ -- 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 (Nov 2012, #02; Fri, 9)
On Fri, Nov 09, 2012 at 09:06:47PM +0100, Ralf Thielow wrote: It seems that the repo doesn't contain the integration branches?!? $ git remote add peff git://github.com/peff/git.git $ git fetch -v peff From git://github.com/peff/git * [new branch] maint - peff/maint * [new branch] master - peff/master * [new branch] next - peff/next * [new branch] pu - peff/pu * [new branch] todo - peff/todo $ But integration branches means master, next and pu than I haven't said anything. ;) Sorry for the noise. Right. :) I have not been pushing the individual topic branches to make life easier for people who usually just track Junio's kernel.org repository, and would not welcome suddenly getting a hundred extra remote branches. I can make them public if it makes life easier for people, but it may not be worth it at this point, with Junio returning soon. -Peff -- 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 (Nov 2012, #02; Fri, 9)
Jeff King p...@peff.net writes: I have not been pushing the individual topic branches to make life easier for people who usually just track Junio's kernel.org repository, and would not welcome suddenly getting a hundred extra remote branches. I can make them public if it makes life easier for people, but it may not be worth it at this point, with Junio returning soon. What we should have arranged was to have https://github.com/git/git (which is not even owned by me, but I asked somebody at GitHub to assign me a write privilege) writable by the interim maintainer, so that normal people would keep pulling from there, while the interim maintainer can choose to publish broken-out branches to his repository. And it is not too late to do so; from the look of your What's cooking, you are doing pretty well ;-). -- 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
Help requested - trying to build a tool doing whole-tree commits
(Apologies if this arrives twice. I'm on the road, with somewhat flaky email.) Because of my work on reposurgeon, I am sometimes asked to produce git repositories for very old projects that not only are still using CVS but have ancient releases not in the CVS repository, preserved only as tarballs. I have such a request currently pending from the robotfindskitten project. To automate this process, I am trying to write a tool that will take a sequence of file trees and synthetic change comments in one end and emit a git repository composing them into a DAG out the other. The working name for this tool is 'gitpacker'. I've already written the unpacking operation (git repo to tree sequence plus log). This morning I discovered that git-commit won't do quite what I need for the packing operation. I'm requesting help. I need a command or command sequence that will commit an entire file tree to a repository... (a) Allowing me to specify committer and author metadata, and (b) deleting paths not present in the previous commit on the current branch, and (c) allowing me to specify merge links from other previous commits. git commit -a passes (a) and (b) but not (c). Advice on how to accomplish this is requested Advice on a better name for the tool is also requested, as I'm not happy with the way my use of 'pack' collides with existing git use of the same verb. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) -- 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: orphan blob or what?
On Fri, 09 Nov 2012 11:37:04 -0800, bruce bruce.e.robert...@intel.com wrote: Tomas Carnecky tomas.carne...@gmail.com writes: Just idiocy on my part. Thanks. On Thu, 08 Nov 2012 16:24:36 -0800, bruce bruce.e.robert...@intel.com wrote: In today's and older clones of https://github.com/mirrors/linux.git I find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it, can't see it via 'git log'. And yet linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile, 2010-09-29) references this blob. It wasn't easy to find the commit. First I figured out at which path that file was stored. Using git log -S'wm8962_reg[WM8962_MAX_REGISTER + 1]' I quickly determined that the file was somewhere in sound/, more specifically sound/soc/codecs/wm8962-tables.c. However a 'git log -- sound/soc/codecs/wm8962-tables.c' did not show any commit. That was strange, because 'git log -S'WM8962_MAX_REGISTER + 1' --name-status -- sound/soc/codecs/' clearly shows that the file existed at some point in the past. The commit is hidden from a simple 'git log' due to 'History Simplification'. See the git-log man page. I added --full-history -p to the log command, and searched in the pager for '6fa98e'. That revealed the commit which references that blob: git log --full-history -p -- sound/soc/codecs/wm8962-tables.c -- 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: Help requested - trying to build a tool doing whole-tree commits
Unknown unknown@unknown.invalid writes: I need a command or command sequence that will commit an entire file tree to a repository... (a) Allowing me to specify committer and author metadata, and (b) deleting paths not present in the previous commit on the current branch, and (c) allowing me to specify merge links from other previous commits. git commit -a passes (a) and (b) but not (c). git commit -a won't add new files, so you probably want to use git add -A git commit. I'm not quite sure what you mean with merge links, but if you want to create merge commits the you'll need to resort to plumbing: git add -A git write-tree git commit-tree git update-ref. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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 (Nov 2012, #02; Fri, 9)
Jeff King p...@peff.net writes: Comments welcome from people using unusual editors (e.g., a script that starts an editor in another window then blocks, waiting for the user to finish). I often run a shell in Emacs in X, then start git commit in that shell. $EDITOR is emacsclient --current-frame, which asks the existing Emacs instance to load the file and waits until I press C-x # in Emacs to mark the file done. If I want to abort the commit, it is most intuitive to return to the *Shell* buffer in Emacs and press C-c C-c (comint-interrupt-subjob) to send SIGINT to git from there. (I see that an empty message aborts the commit, and indeed it does, but well, I prefer not to trust such a feature if I can instead just interrupt the thing.) With pf/editor-ignore-sigint, C-c C-c in the *Shell* buffer kills neither git nor the emacsclient started by git. This is not good. SIGQUIT from C-c C-\ (comint-quit-subjob) still works though. -- 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 (Nov 2012, #02; Fri, 9)
Hi, On Fri, Nov 9, 2012 at 8:23 PM, Jeff King p...@peff.net wrote: * fc/fast-export-fixes (2012-11-08) 14 commits - fast-export: don't handle uninteresting refs - fast-export: make sure updated refs get updated - fast-export: fix comparison in tests - fast-export: trivial cleanup - remote-testgit: make clear the 'done' feature - remote-testgit: report success after an import - remote-testgit: exercise more features - remote-testgit: cleanup tests - remote-testgit: remove irrelevant test - remote-testgit: get rid of non-local functionality - Add new simplified git-remote-testgit - Rename git-remote-testgit to git-remote-testpy - remote-testgit: fix direction of marks - fast-export: avoid importing blob marks Improvements to fix fast-export bugs, including how refs pointing to already-seen commits are handled. An earlier 4-commit version of this series looked good to me, but this much-expanded version has not seen any comments. Needs review. I can send the previous 4-commit version if needed, the only thing that changed is the commit messages. I think it's unfortunate that 4-commit version would not be mentioning that it fixes the above tests, but hey; I did what I could. * fc/zsh-completion (2012-10-29) 3 commits - completion: add new zsh completion - completion: add new __gitcompadd helper - completion: get rid of empty COMPREPLY assignments There were some comments on this, but I wasn't clear on the outcome. Need to take a closer look. SZEDER should probably take a look. I think it should be better than the previous series. * fc/completion-test-simplification (2012-10-29) 2 commits - completion: simplify __gitcomp test helper - completion: refactor __gitcomp related tests Clean up completion tests. There were some comments on the list. Expecting a re-roll. The second patch I can re-roll, but the first patch needs some external input. My preference is that tests should also be simple and maintainable, SZEDER's preference is that tests are better being explicit and verbose (even if harder to maintain) to minimize possible issues in the tests. * fc/remote-testgit-feature-done (2012-10-29) 1 commit - remote-testgit: properly check for errors Needs review. Sverre probably should reply. I think I already addressed his comments and the patch should be OK to push. But probably it's not that important considering the testgit refactoring, and also I'm thinking that we need to actually check the status of the process[1] because the situation is still not OK with pushing, and I'm learning it the hard way with a buggy remote helper. * fc/remote-bzr (2012-11-08) 5 commits - remote-bzr: update working tree - remote-bzr: add support for remote repositories - remote-bzr: add support for pushing - remote-bzr: add simple tests - Add new remote-bzr transport helper New remote helper for bzr. Will merge to 'next'. I already have a newer version of this with support for special modes: executable files, symlinks, etc. I think a reroll would make sense. * fc/remote-hg (2012-11-04) 16 commits - remote-hg: the author email can be null - remote-hg: add option to not track branches - remote-hg: add extra author test - remote-hg: add tests to compare with hg-git - remote-hg: add bidirectional tests - test-lib: avoid full path to store test results - remote-hg: add basic tests - remote-hg: fake bookmark when there's none - remote-hg: add compat for hg-git author fixes - remote-hg: add support for hg-git compat mode - remote-hg: match hg merge behavior - remote-hg: make sure the encoding is correct - remote-hg: add support to push URLs - remote-hg: add support for remote pushing - remote-hg: add support for pushing - Add new remote-hg transport helper New remote helper for hg. Will merge to 'next'. :) I have a few patches on top of this, but they can probably wait. Cheers. [1] http://article.gmane.org/gmane.comp.version-control.git/208139 -- Felipe Contreras -- 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 (Nov 2012, #02; Fri, 9)
On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote: * fc/fast-export-fixes (2012-11-08) 14 commits - fast-export: don't handle uninteresting refs - fast-export: make sure updated refs get updated - fast-export: fix comparison in tests - fast-export: trivial cleanup - remote-testgit: make clear the 'done' feature - remote-testgit: report success after an import - remote-testgit: exercise more features - remote-testgit: cleanup tests - remote-testgit: remove irrelevant test - remote-testgit: get rid of non-local functionality - Add new simplified git-remote-testgit - Rename git-remote-testgit to git-remote-testpy - remote-testgit: fix direction of marks - fast-export: avoid importing blob marks Improvements to fix fast-export bugs, including how refs pointing to already-seen commits are handled. An earlier 4-commit version of this series looked good to me, but this much-expanded version has not seen any comments. Needs review. I can send the previous 4-commit version if needed, the only thing that changed is the commit messages. In the actual code, perhaps, but aren't there significant changes to the git-remote-testgit infrastructure that were not originally present? That could use some review. I also seem to recall that the tests in this version rely on the presence of bash; don't we still need to mark the tests with a prerequisite? * fc/completion-test-simplification (2012-10-29) 2 commits - completion: simplify __gitcomp test helper - completion: refactor __gitcomp related tests Clean up completion tests. There were some comments on the list. Expecting a re-roll. The second patch I can re-roll, but the first patch needs some external input. My preference is that tests should also be simple and maintainable, SZEDER's preference is that tests are better being explicit and verbose (even if harder to maintain) to minimize possible issues in the tests. I think it is better to keep the tests simple and maintainable. If there are multiple ways to do things and they all need testing, then that should be clear from the tests, not done haphazardly because some tests happen to use a different way of doing things. I seem to recall there was a one-liner fix that needed to be rolled in, which is why I held it out of next. * fc/remote-bzr (2012-11-08) 5 commits - remote-bzr: update working tree - remote-bzr: add support for remote repositories - remote-bzr: add support for pushing - remote-bzr: add simple tests - Add new remote-bzr transport helper New remote helper for bzr. Will merge to 'next'. I already have a newer version of this with support for special modes: executable files, symlinks, etc. I think a reroll would make sense. Thanks for letting me know. -Peff -- 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 (Nov 2012, #02; Fri, 9)
On Fri, Nov 09, 2012 at 12:27:35PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: I have not been pushing the individual topic branches to make life easier for people who usually just track Junio's kernel.org repository, and would not welcome suddenly getting a hundred extra remote branches. I can make them public if it makes life easier for people, but it may not be worth it at this point, with Junio returning soon. What we should have arranged was to have https://github.com/git/git (which is not even owned by me, but I asked somebody at GitHub to assign me a write privilege) writable by the interim maintainer, so that normal people would keep pulling from there, while the interim maintainer can choose to publish broken-out branches to his repository. Yes, I have write access to that repository, too, but I intentionally held off from updating it out of a sense of nervousness. I figured if I screwed up anything too badly, people who were clued-in enough to switch to pulling from my repository would be clued-in enough to rebase across any too-horrible mistake I made. ;) I think if we do this again, I will make the same split you do (git/git for integration branches, peff/git as a mirror of my private repo). And it is not too late to do so; from the look of your What's cooking, you are doing pretty well ;-). Any fool can merge topics to master. The real test will be how many regressions people report in the next two weeks. :) By the way, I did not touch 'maint' at all while you were gone. I don't know what your usual method is for keeping track of maint-worthy topics after they have gone to master. The usual what's cooking workflow keeps track of things going to master, but no more; I'd guess you probably just merge to maint when you delete them from last cycle's graduated to master list. I just let them stew in master for a bit longer, and we can easily find and merge them with git branch --no-merged maint | grep maint. -Peff -- 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 (Nov 2012, #02; Fri, 9)
On Sat, Nov 10, 2012 at 1:33 AM, Jeff King p...@peff.net wrote: On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote: * fc/fast-export-fixes (2012-11-08) 14 commits - fast-export: don't handle uninteresting refs - fast-export: make sure updated refs get updated - fast-export: fix comparison in tests - fast-export: trivial cleanup - remote-testgit: make clear the 'done' feature - remote-testgit: report success after an import - remote-testgit: exercise more features - remote-testgit: cleanup tests - remote-testgit: remove irrelevant test - remote-testgit: get rid of non-local functionality - Add new simplified git-remote-testgit - Rename git-remote-testgit to git-remote-testpy - remote-testgit: fix direction of marks - fast-export: avoid importing blob marks Improvements to fix fast-export bugs, including how refs pointing to already-seen commits are handled. An earlier 4-commit version of this series looked good to me, but this much-expanded version has not seen any comments. Needs review. I can send the previous 4-commit version if needed, the only thing that changed is the commit messages. In the actual code, perhaps, but aren't there significant changes to the git-remote-testgit infrastructure that were not originally present? That could use some review. I also seem to recall that the tests in this version rely on the presence of bash; don't we still need to mark the tests with a prerequisite? I meant in the 4-commits. * fc/completion-test-simplification (2012-10-29) 2 commits - completion: simplify __gitcomp test helper - completion: refactor __gitcomp related tests Clean up completion tests. There were some comments on the list. Expecting a re-roll. The second patch I can re-roll, but the first patch needs some external input. My preference is that tests should also be simple and maintainable, SZEDER's preference is that tests are better being explicit and verbose (even if harder to maintain) to minimize possible issues in the tests. I think it is better to keep the tests simple and maintainable. If there are multiple ways to do things and they all need testing, then that should be clear from the tests, not done haphazardly because some tests happen to use a different way of doing things. Good, that's what my first patch does; no functional changes, just refactor code into a single function. I seem to recall there was a one-liner fix that needed to be rolled in, which is why I held it out of next. Yes, that I can reroll. Cheers. -- Felipe Contreras -- 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 0/5] push: update remote tags only with force
On Fri, Nov 9, 2012 at 12:38 PM, Jeff King p...@peff.net wrote:
On Sun, Nov 04, 2012 at 09:08:23PM -0600, Chris Rorvick wrote:
Patch series to prevent push from updating remote tags w/o forcing them.
Split out original patch to ease review.
Chris Rorvick (5):
push: return reject reasons via a mask
push: add advice for rejected tag reference
push: flag updates
push: flag updates that require force
push: update remote tags only with force
Documentation/git-push.txt | 10 +-
builtin/push.c | 24 +++-
builtin/send-pack.c|6 ++
cache.h|7 ++-
remote.c | 39 +++
t/t5516-fetch-push.sh | 30 +-
transport-helper.c |6 ++
transport.c| 25 +++--
transport.h| 10 ++
9 files changed, 119 insertions(+), 38 deletions(-)
I have not looked carefully at this topic yet, but I did try merging it
to pu and found that it had some textual conflicts with the
nd/builtin-to-libgit topic, which moves some builtin/send-pack.c code to
send-pack.c. Since I am graduating that topic to master, I went ahead
and just rebased your topic on top.
If you do a re-roll, please use an updated master, and feel free to
grab (and double-check!) the rebase I am about to send out in 'pu'. I
also included the minor signed/unsigned pointer warning fixup in the
rebase, too.
-Peff
Thanks, I've rebased and checked against the changes in pu. Looks
good to me. I have a couple of other minor fixes (see below for
details.) I'll include these in an update if there is sufficient
interest in this.
Chris
-- 8 --
diff --git a/remote.c b/remote.c
index fde2a79..b025a38 100644
--- a/remote.c
+++ b/remote.c
@@ -1351,9 +1351,8 @@ void set_ref_status_for_push(struct ref
*remote_refs, int send
if (ref-update) {
ref-nonfastforward =
- ref-update
- (!has_sha1_file(ref-old_sha1)
- || !ref_newer(ref-new_sha1, ref-old_sha1));
+ !has_sha1_file(ref-old_sha1)
+ || !ref_newer(ref-new_sha1, ref-old_sha1);
if (!ref-forwardable) {
ref-requires_force = 1;
diff --git a/transport.c b/transport.c
index c183971..a380ad7 100644
--- a/transport.c
+++ b/transport.c
@@ -749,7 +749,7 @@ void transport_print_push_status(const char *dest,
struct ref *r
else
*reject_mask |= REJECT_NON_FF_OTHER;
} else if (ref-status == REF_STATUS_REJECT_ALREADY_EXISTS) {
- *reject_mask |= REJECT_ALREADY_EXISTS;
+ *reject_mask |= REJECT_ALREADY_EXISTS;
}
}
}
--
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: Rename edge case...
On Fri, Nov 9, 2012 at 11:09 AM, Jeff King p...@peff.net wrote: [snip] Right. If the source didn't go away, it would be a copy. We can do copy detection, but it is not quite as obvious what a merge should do with a copy (apply the change to the original? To the copy? In both places? You would really want hunk-level copy detection for it to make any sense). Yeah, I wasn't advocating that. More along the lines of what you're talking about below... Usually git deals with this double-rename case through the use of break or rewrite detection. We notice that the old foo.txt and the new foo.txt do not look very much like each other, and break the modification apart into an add and a delete. That makes each side eligible for rename detection, and we can end up finding the pairs of renames above. I did try using the -B option, and it did detect that foo.txt was renamed to fooOld.txt, but it didn't show fooNew.txt being renamed to foo.txt. I'm running git 1.7.12.3. It could be that 1.8.0 does better, but I haven't tried. So in theory it just as simple as a one-liner to turn on break-detection in merge-recursive. Sadly, that only reveals more issues with how merge-recursive handles renames. See this thread, which has pointers to the breakages at the end: http://thread.gmane.org/gmane.comp.version-control.git/169944 Thank you. I'll definitely read up on this. I've become convinced that the best way forward with merge-recursive is to scrap and rewrite it. It tries to do things in a muddled order, which makes it very brittle to changes like this. I think it needs to have an internal representation of the tree that can represent all of the conflicts, and then follow a few simple phases: 1. structural 3-way merge handling renames, breaks, typechanges, etc. Each path in tree might show things like D/F conflicts, or it might show content-level merges that still need to happen, even if the content from those merges is not coming from the same paths in the source trees. 2. Resolve content-level 3-way merges at each path. 3. Compare the proposed tree to the working tree and list any problems (e.g., untracked files or local modifications that will be overwritten). Right now it tries to do these things interleaved as it processes paths, and as a result we've had many bugs (e.g., the content-level merge conflating the content originally at a path and something that was renamed into place, and missing corner cases where we actually overwrite untracked files that should be considered precious). But that is just off the top of my head. I haven't looked at the topic in quite a while (and I haven't even started working on any such rewrite). That certainly sounds like a better approach. So I played locally with a few ideas, and was surprised to find out that even breaking up the two renames into two separate commits git still didn't follow it. Right, because the merge only looks at the end points. Try doing a diff -M between your endpoints with and without -B. We do not have any double-renames in git.git, but you can find -B helping a similar case: most of a file's content is moved elsewhere, but some small amount remains. For example, try this in git.git, with and without -B: git show -M --stat --summary --patch 043a449 It finds the rename only with -B, which would help a merge (it also makes the diff shorter and more readable, as you can see what was changed as the content migrated to the new file). I've played with the -B option before, and it's definitely nice in certain cases. Thank you for taking the time to write all this up. It was very informative! -John -- 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: Workflow for templates?
I am somewhat unsure whether it would work this way. After all, there seems to be an unbreakable rule with git: never rebase published branches. I dont see a big problem if you just tell the downstreams to rebase instead of merge downwards. That's eg. my default approach for handling things like local customizations. The fine thing here is that you'll always have a clear separation between upstream development and your customizations. Let's say, you have once forked at release tag v1.2.3, added 3 customization commits and later rebase onto v1.2.4, you'll still have your 3 customization commits ontop of the upstream release. With merge, you'll get more and more merge commits mixed later coming customizations, and a migh higher chance of repeating conflicts. I'd suggest some general rules: * strict branch hierachy * downstreams always rebase instead of merge * probably use --onto rebase * development is always happening in topic-branches, that will be rebased before merge into their upstream -- fast-forward only Maybe I should try to explain the problem in terms of repository hierarchy. Let's assume, there is this hierarchy of repositories: Let's talk about branches instead - repos are just containers for branches (and tags, etc). If all people are practically in the same administrative domain (or sort of), you can even use one single repo for that (not counting developer's and target system's local clones). upstream: central repository, containing the generic template foo-site: repository for site foo. Here we have localizations for a specific administrative entity named foo (say, google). This is where clones for production are made from, and production boxes pull from here to be kept up-to-date. Only the non-customized boxes will pull from here - if there's any bit that needs to be changed, add separate branches for them. And pull always means rebase. When a new upstream release comes out (and is properly validated), it will be rebased ontop of that. foo-devA: A clone of foo-site to make development, releases, and whatever for foo. foo-devB: One more clone of foo-site, Developer B is working here. Developers should use topic branches, which are regularily rebased ontop of their upstream, especially before commit and final validation. Further, foo-devA might be the same person as bar-devA. He'll use separate branches anyways. Everything else is just a matter of proper naming scheme. For example, if you're using a central (bare) repository (again: not counting the developer's locl clones), you could use something like an site+/ branch name prefix. By the way: you really should use non-conflicting tag names (eg. adding some site+/ or site+- prefix), otherwise you'll easiy run into conflicts, because per default retrieved and local tags will all be in some namespace - you'll probably dont like to set up separate namespaces for individual remotes (which is quite easy to forget ;-o). Better consider tag names to be really global. So when foo-devA pulls from foo-devB, then foo-devB will create problems when he rebases after that pull. pull (or probably: remote update) is different from merge or rebase essentially, pull is a combination of remote update and an automatic merge from or rebase onto (depending on the configuration) the coresponding upstream branch. What I am trying to achieve, is to extend the workflow from development to deployment across multiple administrative entities. As a picture: upstream (templates only). ^ | v development (configured, might contain experimental changes) ^ | v deployment (configured) This workflow should not stop at administrative borders. Just replace foo by google and bar by Microsoft to get an idea of what I am trying to achieve. We're talking about two entirely different things here: a) repositories: container that hold references to histories (branches, tags, etc) b) branches and their semantic releations Repositories: As git is fully distributed, it doesnt really matter where repositories are. Developers (and other parties accessing the code) will most likely have their own local clone. But clone of X means nothing more than just happens to have some remote attachment to repo X. So, the semantics of git clone /path/to/my/funny-project is the same like: ( git init funny-project \ cd cd funny-project \ git remote add origin /path/to/my/funny-project \ git remote update origin \ git checkout origin/master -b master ) So, let's look at the individual steps: #1: git init funny-project -- ( mkdir funny-project cd funny-dir git init ) -- creates an empty repository #2: git remote add origin /path/to/my/funny-project -- configures an remote called origin with url /path/to/my/funnly-project and confgures it to sync the remote-side's references from
Re: Workflow for templates?
Let me ask a different question: What is wrong with cherry-picking downstream changes to your upstream branch? Without rebasing it to downstream. Naah, dont rebase the upstream ontop of downstream - this doenst make any sense (yeah, my devs sometimes doing exatly this wong ;-o). Instead, as you just said, cherry-pick the good commits into your upstream branch and rebase your downstreams ontop of that. (doesnt make any difference if this is done by different people or in different administrative domains). That might mean there is a rather useless merge downstream later on, but that's the price you pay for not doing the change in a development branch. That's one of the things rebase is for: not having your history filled up with merges at all, but always have your local cutomizations added ontop of the current upstream. By the way: I'm also using this hierachy for package maintenance to different target distros: upstream branch | | upstream release tag X.Y.Z | \ / bugfix branch (maint-X-Y-Z) = general (eg. distro-agnostig) fixes go here | |- maintenance release tag X.Y.Z.A | \ / dist branch (mydist-X-Y-Z) = distro-specific customizations (eg. | packaging control files, etc) go here |-- dist package release tags X.Y.Z.A-B Usually I do quick hotfixes in the dist branch (and assigning new dist version number), then copy the dist branch into some topic-branch, rebase into latest bugfix branch, cherry-pick the interesting commit(s) into the bugfix branch. When I do a new bugfix release (from by bugfix branch), I rebase the dist branch ontop the latest bugfix release tag, fix dist-package version numbers and run the dist-specific build and testing pipeline. Here's some example for it: https://github.com/vnc-biz/redmine-core cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: Bizarre problem cloning repo from Codeplex
I'm trying to clone the following repository from Codeplex: https://git01.codeplex.com/entityframework.git git downloads all the objects, creates the directory entityframework, then displays error: RPC failed; result=56, HTTP code = 200 and immediately deletes the directory. I can clone other HTTPS repos with this git installation, for example from Bitbucket and Github. It's git 1.7.10.4 on Debian. reproduced it on Ubuntu precise, git-1.7.9.5 When starting with an empty repo, adding the url as remote and calling git remote update origin: Fetching origin WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-5cWq1d/pkcs11: No such file or directory remote: Counting objects: 21339, done. remote: Compressing objects: 100% (3778/3778), done. remote: Total 21339 (delta 17180), reused 21339 (delta 17180) Receiving objects: 100% (21339/21339), 11.24 MiB | 1.04 MiB/s, done. error: RPC failed; result=56, HTTP code = 200 Resolving deltas: 100% (17180/17180), done. error: Could not fetch origin But: refs/remotes/origin/master is added and looks sane (git fsck shows no errors). Subsequent 'git remote update' calls look good: Fetching origin Even after manually removing the ref and re-running update, everything look fine: Fetching origin WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-5cWq1d/pkcs11: No such file or directory From https://git01.codeplex.com/entityframework * [new branch] master - origin/master Their webserver seems to be configured quite restrictively (eg. cannot access files like 'packed-refs'). Is there a way to trace the actual HTTP calls ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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-svn with ignore-paths misses/skips some revisions during fetch
The problem is that the 'ignore-paths' approach sometimes misses commits during a fetch, and then at some later time will realize it and squash those changes onto some other, unrelated commit. (I've never seen this happen with the per-subdir 'fetch' approach.) Here are three commits in SVN: Could it be that certain files spent parts of their historical lifetime inside the ignored paths ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
