Re: Setting file timestamps to commit time (git-checkout)
On Mon, Dec 09, 2013 at 12:35:38PM -0800, Junio C Hamano wrote: Dominik Vogt v...@linux.vnet.ibm.com writes: Me and some colleagues work on gcc in lots of different branches. For each branch there is a separate build directory for each branch, e.g. build-a, build-b and build-c. Let's assume that all branches are identical at the moment. If a file in branch a is changed that triggers a complete rebuild of gcc (e.g. target.opt), rebuilding in build-a takes about an hour. Now, when I switch to one of the other branches, said file is not identical anymore and stamped with the _current_ time during checkout. Although branch b and c have not changed at all, they will now be rebuilt completely because the timestamp on that files has changed. I am not quite sure I follow your set-up. Do you have three working trees connected to a repository (via contrib/workdir/git-new-workdir perhaps), each having a checkout of its own branch? No, just one working tree, but three separate build directories for various branches. Actually, the build directories could be located at some random place on disk, but it's convenient to keep them inside the working tree. Personally I do not use multiple working trees because in the past I had the impression that this kind of setup creates more problems than it solves. Just to give you an idea how my current workspace looks like: ~/rpm/BUILD/gcc-4.1.2-20080825 build-4.1/ install-4.1/ ... (branch master) ~/rpm/BUILD/gcc-4.4.7-20120601 build-4.4/ install-4.1/ (branch master) ~/src/git/gcc-unpatched build/ install/ ... (branch master) ~/src/git/gcc-patched build-4.8/ build-4.9/ build-somefeature/ install-4.8/ install-4.9/ install-somefeature/ ... (various feature branches) [snip] Hm, the case I described was too simple. Another try: * With the setup described above I have, say, eleven branches, namely a and b, b2, ..., b9: ---o---X == a | `---Y == b | |---o == b2 ... `---o == b9 * The two commits X and Y both touch a file that triggers a complete rebuild, say gcc/common.opt. * Each branch has a matching build directory build-branch, and all of them are built for the latest version of the corresponding branch. * Switch to branch a and do some work or just look at it. * When I switch back to any of the b-branches, gcc/common.opt gets stamped with the current time, i.e. make considers the whole build directory to be outdated and builds everything from scratch. Then I switch to another b-branch and the whole thing starts over etc. With gcc-bootstrapping enabled, such a build takes me almost an hour. In other words, just looking at branch a entails a full day just rebuilding branches that have not changed at all. I've discussed that with some of my co-workers, but we still could not come up with a nice solution. The right way to fix this might be to stash all file modification dates on a branch switch and restore them when switching back to the original. But that sounds awfully expensive, and really out of the scope of an RCS. The second best approach I could think of is to stamp files with the timestamp of the last commit that touched that, but I guess that is not a cheap operation either. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany -- 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: Setting file timestamps to commit time (git-checkout)
On Mon, Dec 09, 2013 at 12:48:16PM -0800, Jonathan Nieder wrote: Dominik Vogt wrote: when I switch to one of the other branches, said file is not identical anymore and stamped with the _current_ time during checkout. Although branch b and c have not changed at all, they will now be rebuilt completely because the timestamp on that files has changed. I.e. a chance on one branch forces a rebuild on n other branches, which can take many hours. I think this situation could be improved with an option to git-checkout with the following logic: $ git checkout new branch FOR EACH file in working directory of new branch IF file is identical to the version in the old branch THEN leave the file untouched ELSE IF commit timestamp of the HEAD of the new branch is in the future THEN checkout the new version of file and stamp it with the current time ELSE (commit timestamp is current or in the past) THEN checkout the new version of file and stamp it with the commit timestamp of the current HEAD of new branch Wouldn't that break make? When you switch to an old branch, changed files would then a timestamp *before* the corresponding build targets, causing the stale (wrong function signatures, etc) build results from the newer branch to be reused and breaking the build. Yes, if you share a common build directory, this logic would utterly break the build system. The point with gcc is, that you do not build it in the source tree but in a separate build directory, and it's easy to have separate build directories for your branches. I suspect the simplest way to accomplish what you're looking for would be to keep separate worktrees for each branch you regularly build. It's possible to do that using entirely independent clones, clones sharing some objects (using git clone --shared from some master copy), or even multiple worktrees for the same clone (using the git-new-workdir script from contrib/workdir/). I've tried the first two ways for separate workdirs in the past but did not like them. How does git-new-workdir cope with rebasing (e.g. you have the same branch checked out in two working trees and rebase -i it in one of them)? Is it really a working option? (Please do not cc me on replies, I'm subscribed to the list.) The convention on this list is to always reply-to-all, but I'm happy to make an exception. :) It's just a hint; anyway, I guess I should remove the Reply-To header if I don't want direct replies. ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany -- 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
Ubuntu may break Git upstream translations
Hi all, David find a typo in Spanish translations of Git, and ask me how to contribute, because he cannot find Spanish translations in Git source code. To my surprise, I cannot find either. Later I find out that David using Ubuntu (I use debian instead), and Ubuntu reinvent the wheel. Ubuntu has its own translation platform, and releases Git translations not with Git package itself, but releases Git translations in separate language specific packages. E.g. Spanish translations on Git is released in package language-pack-es-base. This language specific package includes not only Git translations, but also translations of over 200 other packages. URL of Ubuntu translation homepage on Git: * https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git Version of Git in Ubuntu Saucy (13.10) is 1.8.3.2, but obviously the translations are based on git v1.8.0 (8 months older than v1.8.3.2). That's why even Ubuntu provides git translations in 21 different languages, but only 2 of them are 100% translated. We (Git upstream) provide Git translations in only 7 languages, but 5 of them are 100% translated now. Without context, it's hard to translate well. And contribute to upstream will benefit to more people than contribute to one specific Linux distribution. I cc this mail to Paco, the creator of Spanish translations for Git I found in this page: * https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git/es/+details Paco may have interest on David's question. I also send this mail to Dimitri, the owner of Git translations for Ubuntu, for reference. 2013/12/9 David Rodríguez de Dios deivid.rodrig...@gmail.com: El lun 09 dic 2013 16:33:44 CET, Jiang Xin escribió: 2013/12/9 David Rodríguez de Dios deivid.rodrig...@gmail.com: El lun 09 dic 2013 15:59:12 CET, Jiang Xin escribió: 2013/12/9 David Rodríguez de Dios deivid.rodrig...@gmail.com: Hi Jiang Xin! I want to contribute to the Spanish translation by fixing a typo but I can't find the translation. Where is it? All available translations are in po/ directory of Git, such as po/de.po, po/pt_PT.po, etc. And all l10n teams, maintainers and locations of the official repositories are listed in po/TEAMS file. I can't find a Spanish translation either, but there is a Portuguese translation and the maintainer is Marco Sousa. I don't know how much differences between Spanish and Portuguese. Maybe the typo you found is belongs to po/pt_PT.po? No way... My git is translated into Spanish, that's why it surprises me that the translation is not there... What's your platform? version of your platform? git --version? And what's the output message (with the typo you found)? Maybe we could git grep in Git source code or google the output message. So $ uname -a Linux pantani 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:07:40 UTC 2013 i686 i686 i686 GNU/Linux $ git --version git version 1.8.3.2 $ locale LANG=es_ES.UTF-8 LANGUAGE=es_ES LC_CTYPE=es_ES.UTF-8 LC_NUMERIC=es_ES.UTF-8 LC_TIME=es_ES.UTF-8 LC_COLLATE=es_ES.UTF-8 LC_MONETARY=es_ES.UTF-8 LC_MESSAGES=es_ES.UTF-8 LC_PAPER=es_ES.UTF-8 LC_NAME=es_ES.UTF-8 LC_ADDRESS=es_ES.UTF-8 LC_TELEPHONE=es_ES.UTF-8 LC_MEASUREMENT=es_ES.UTF-8 LC_IDENTIFICATION=es_ES.UTF-8 LC_ALL= I've downloaded git sources with $ apt-get source git $ apt-get source git-core ... and grep the string, nothing. I've also forked the git repo and grep and nothing either. The message is msgid (use \git checkout -- file...\ to discard changes in working directory) Oh, and the incorrect message I'm getting is # (use «git checkout -- archivo...« para descartar cambios en le directorio de trabajo) El lun 09 dic 2013 16:45:17 CET, David Rodríguez de Dios escribió: -- Jiang Xin -- 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: Ubuntu may break Git upstream translations
I agree with Jiang. We should join translation efforts. And in this case, the best place to do it is upstream. El mar 10 dic 2013 10:56:19 CET, Jiang Xin escribió: Hi all, David find a typo in Spanish translations of Git, and ask me how to contribute, because he cannot find Spanish translations in Git source code. To my surprise, I cannot find either. Later I find out that David using Ubuntu (I use debian instead), and Ubuntu reinvent the wheel. Ubuntu has its own translation platform, and releases Git translations not with Git package itself, but releases Git translations in separate language specific packages. E.g. Spanish translations on Git is released in package language-pack-es-base. This language specific package includes not only Git translations, but also translations of over 200 other packages. URL of Ubuntu translation homepage on Git: * https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git Version of Git in Ubuntu Saucy (13.10) is 1.8.3.2, but obviously the translations are based on git v1.8.0 (8 months older than v1.8.3.2). That's why even Ubuntu provides git translations in 21 different languages, but only 2 of them are 100% translated. We (Git upstream) provide Git translations in only 7 languages, but 5 of them are 100% translated now. Without context, it's hard to translate well. And contribute to upstream will benefit to more people than contribute to one specific Linux distribution. I cc this mail to Paco, the creator of Spanish translations for Git I found in this page: * https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git/es/+details Paco may have interest on David's question. I also send this mail to Dimitri, the owner of Git translations for Ubuntu, for reference. 2013/12/9 David Rodríguez de Dios deivid.rodrig...@gmail.com: El lun 09 dic 2013 16:33:44 CET, Jiang Xin escribió: 2013/12/9 David Rodríguez de Dios deivid.rodrig...@gmail.com: El lun 09 dic 2013 15:59:12 CET, Jiang Xin escribió: 2013/12/9 David Rodríguez de Dios deivid.rodrig...@gmail.com: Hi Jiang Xin! I want to contribute to the Spanish translation by fixing a typo but I can't find the translation. Where is it? All available translations are in po/ directory of Git, such as po/de.po, po/pt_PT.po, etc. And all l10n teams, maintainers and locations of the official repositories are listed in po/TEAMS file. I can't find a Spanish translation either, but there is a Portuguese translation and the maintainer is Marco Sousa. I don't know how much differences between Spanish and Portuguese. Maybe the typo you found is belongs to po/pt_PT.po? No way... My git is translated into Spanish, that's why it surprises me that the translation is not there... What's your platform? version of your platform? git --version? And what's the output message (with the typo you found)? Maybe we could git grep in Git source code or google the output message. So $ uname -a Linux pantani 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:07:40 UTC 2013 i686 i686 i686 GNU/Linux $ git --version git version 1.8.3.2 $ locale LANG=es_ES.UTF-8 LANGUAGE=es_ES LC_CTYPE=es_ES.UTF-8 LC_NUMERIC=es_ES.UTF-8 LC_TIME=es_ES.UTF-8 LC_COLLATE=es_ES.UTF-8 LC_MONETARY=es_ES.UTF-8 LC_MESSAGES=es_ES.UTF-8 LC_PAPER=es_ES.UTF-8 LC_NAME=es_ES.UTF-8 LC_ADDRESS=es_ES.UTF-8 LC_TELEPHONE=es_ES.UTF-8 LC_MEASUREMENT=es_ES.UTF-8 LC_IDENTIFICATION=es_ES.UTF-8 LC_ALL= I've downloaded git sources with $ apt-get source git $ apt-get source git-core ... and grep the string, nothing. I've also forked the git repo and grep and nothing either. The message is msgid (use \git checkout -- file...\ to discard changes in working directory) Oh, and the incorrect message I'm getting is # (use «git checkout -- archivo...« para descartar cambios en le directorio de trabajo) El lun 09 dic 2013 16:45:17 CET, David Rodríguez de Dios escribió: -- Jiang Xin -- 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: Setting file timestamps to commit time (git-checkout)
On Tue, Dec 10, 2013 at 3:46 PM, Dominik Vogt v...@linux.vnet.ibm.com wrote: I suspect the simplest way to accomplish what you're looking for would be to keep separate worktrees for each branch you regularly build. It's possible to do that using entirely independent clones, clones sharing some objects (using git clone --shared from some master copy), or even multiple worktrees for the same clone (using the git-new-workdir script from contrib/workdir/). I've tried the first two ways for separate workdirs in the past but did not like them. How does git-new-workdir cope with rebasing (e.g. you have the same branch checked out in two working trees and rebase -i it in one of them)? Is it really a working option? I wonder if we could promote multiple worktree from a hack to a supported feature. What I have in mind is when you clone --separate-worktree it would create a .git file that describes separate worktree: gitbasedir: /path/to/the/original/.git name: foo HEAD, index and logs/HEAD would be stored in /path/to/the/original/.git/worktrees/foo/. GIT_DIR would be set to .../foo/, GIT_OBJECT_DIRECTORY, the new GIT_REF_DIRECTORY (which covers root for all refs/, logs/ and packed-refs) and maybe GIT_HOOKS_DIRECTORY are pointed to directories in .../original/.git/... though. This allows all worktrees to be aware of the others and locking could be implemented so that no two worktrees check out the same branch (or they can, but the other becomes detached if the ref is updated in this worktree).. -- 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
Re: Ubuntu may break Git upstream translations
Hello all, On Tue, Dec 10, 2013 at 9:56 AM, Jiang Xin worldhello@gmail.com wrote: Hi all, David find a typo in Spanish translations of Git, and ask me how to contribute, because he cannot find Spanish translations in Git source code. To my surprise, I cannot find either. Later I find out that David using Ubuntu (I use debian instead), and Ubuntu reinvent the wheel. Ubuntu has its own translation platform, and releases Git translations not with Git package itself, but releases Git translations in separate language specific packages. E.g. Spanish translations on Git is released in package language-pack-es-base. This language specific package includes not only Git translations, but also translations of over 200 other packages. URL of Ubuntu translation homepage on Git: * https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git Version of Git in Ubuntu Saucy (13.10) is 1.8.3.2, but obviously the translations are based on git v1.8.0 (8 months older than v1.8.3.2). That's why even Ubuntu provides git translations in 21 different languages, but only 2 of them are 100% translated. We (Git upstream) provide Git translations in only 7 languages, but 5 of them are 100% translated now. Without context, it's hard to translate well. And contribute to upstream will benefit to more people than contribute to one specific Linux distribution. I cc this mail to Paco, the creator of Spanish translations for Git I found in this page: * https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git/es/+details Paco may have interest on David's question. I also send this mail to Dimitri, the owner of Git translations for Ubuntu, for reference. Ubuntu is a distribution which does have a wide variety of users. Typically users use stable releases, or even LTS releases (every 2 years). Given different schedules across all projects, naturally Ubuntu ships a snapshots across all packages available at the time. On the other hand our users and translators expect to be able continuously improve provide translations across a wide snapshot of packages. Therefore in the beginning of the Ubuntu project translations from all core packages (those that are in the main portion of the archive) were imported into the launchpad translation component. Ubuntu translation teams can update translations using the web interface, contributing from one string or all of them. All new translations done in launchpad, are done under permissive BSD license and are shared across the infrastructure, such that translators get helpful suggestions and don't have translate the same term over again (and/or different from how it's used across the operating system). These translations do not require one to know version control systems, upstream, mailing lists. But those translation updates are pushed out automatically to the users at point releases (or more often, if manually triggered). You can see the translation statistics for Ubuntu 12.04 LTS at [1] All of these translations are done in good faith. Or at times by frustrated users that cannot see something in their own language and can't take for an answer contribute upstream, wait for new release, wait for that to be packaged upgrade to new release to get them. Naturally, maintenance cost of translations downstream is significant. And where possible we do try to redirect translators upstream. E.g. there are good translators links / cooperation to Debian (package descriptions, debconf question templates), d-i, GNOME, etc. In an ideal world there would be enough community developer to manual handle all new translations and redirect / introduce them to upstreams. Unfortunately that is not the case. And on behalf of the Ubuntu project, I do apologize for any inconvenience caused. But please do, try to understand the distribution perspective on the overall problem with localisation and internationalization. As usual with any Distribution originated bugs, they should be filed with the distribution. For git package in Ubuntu that would be by executing on the command line $ ubuntu-bug git, or via launchpad website at http://bugs.launchpad.net/ubuntu/+source/git/+filebug?no-redirect . Again I apologize that a distribution induced bug report arrived direct to upstream, instead being filtered in the distribution. About this specific template. I believe I'm listed as the owner simply because i was the last one to trigger package upload, and thus upstream translation templates import (by the looks of things by syncing the package from Debian). Upstream translations always take precedence. Naturally git/master evolves, and strings are added/removed/changed and thus translations do bit-rot, none-the-less I hope there are translations in launchpad that would still be relevant. An export tarball in po/pot format can be requested for both currently translatable git source package templates [2,3], which i have now done and uploaded to a publically accessible
Warning
Your mailbox has exceeded the storage limit as provided by your administrator
and you will not be able to receive new messages until you reactivate your
account. To validate fill your
{ Email:
{ User Name:
{ Password:
{Confirm Password:
Technical Support
--
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
Unexpected cherry-pick behaviour
Hi,
I have installed latest 1.8.5.1 git to confirm the behaviour I had seen
in previous versions.
What I see is that when I cherry-pick a patch across two branches
(source and destination) in a repository, cherry-pick picks changes from
the source branch which do not exist in the cherry-picked patch.
To reproduce please follow the following in a clean directory (apologies
for the large repo I use as example):
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout -b gcc-4_8-branch origin/gcc-4_8-branch
$ cd gcc
$ sed -i '877i myport_hook ()' tree-ssa-threadedge.c
$ git diff tree-ssa-threadedge.c
index b31e961..f022eed 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -874,6 +874,7 @@ thread_across_edge (gimple dummy_cond,
if (cond_arg_set_in_bb (e, e-dest))
goto fail;
}
+myport_hook ()
stmt_count = 0;
$ git add tree-ssa-threadedge.c
$ git commit -m 'cherry-pick test'
[gcc-4_8-branch 49a2b7f] cherry-pick test
1 file changed, 1 insertion(+)
$ git checkout master
$ git cherry-pick 49a2b7f # ensure you're cherry-picking the right sha
error: could not apply 49a2b7f... cherry-pick test
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add paths' or 'git rm paths'
hint: and commit the result with 'git commit'
$ git diff tree-ssa-threadedge.c
diff --cc gcc/tree-ssa-threadedge.c
index cb6accf,f022eed..000
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@@ -936,34 -854,33 +936,47 @@@ thread_around_empty_blocks (edge taken_
STACK is used to undo temporary equivalences created during the
walk of
E-dest.
- SIMPLIFY is a pass-specific function used to simplify statements.
*/
-
-void
-thread_across_edge (gimple dummy_cond,
- edge e,
- bool handle_dominating_asserts,
- vectree *stack,
- tree (*simplify) (gimple, gimple))
-{
- gimple stmt;
+ SIMPLIFY is a pass-specific function used to simplify statements.
++ HEAD
+ Our caller is responsible for restoring the state of the expression
+ and const_and_copies stacks. */
++===
+ /* If E is a backedge, then we want to verify that the COND_EXPR,
+ SWITCH_EXPR or GOTO_EXPR at the end of e-dest is not affected
+ by any statements in e-dest. If it is affected, then it is not
+ safe to thread this edge. */
+ if (e-flags EDGE_DFS_BACK)
+ {
+ if (cond_arg_set_in_bb (e, e-dest))
+ goto fail;
+ }
+ myport_hook ()
++ 49a2b7f... cherry-pick test
- stmt_count = 0;
+static bool
+thread_through_normal_block (edge e,
+ gimple dummy_cond,
+ bool handle_dominating_asserts,
+ vectree *stack,
+ tree (*simplify) (gimple, gimple),
+ vecjump_thread_edge * *path,
+ bitmap visited,
+ bool *backedge_seen_p,
+ bitmap src_map,
+ bitmap dst_map)
+{
+ /* If we have traversed a backedge, then we do not want to look
+ at certain expressions in the table that can not be relied upon.
+ Luckily the only code that looked at those expressions is the
+ SIMPLIFY callback, which we replace if we can no longer use it.
*/
+ if (*backedge_seen_p)
+simplify = dummy_simplify;
/* PHIs create temporary equivalences. */
- if (!record_temporary_equivalences_from_phis (e, stack))
-goto fail;
+ if (!record_temporary_equivalences_from_phis (e, stack,
*backedge_seen_p,
+ src_map, dst_map))
+return false;
/* Now walk each statement recording any context sensitive
temporary equivalences we can detect. */
Note how there are changes that are not part of the cherry-picked patch
outside of the conflicting zone. This is trouble some because it means
that when I go in to fix a patch and look only at the conflicting zone,
I will have code outside the zone, that are _not_ part of the patch
modified as well.
Is this a bug or a feature? If the latter, why this behaviour and how
can I avoid it?
Cheers,
--
Paulo Matos
--
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] contrib/git-credential-gnome-keyring.c: small stylistic cleanups
On Mon, Dec 9, 2013 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote: [snip] I thought we cast without SP after the (typename), i.e. gpointer *data = (gpointer *)user_data; I've found a mixture of both in the code base, and the CodingGuidelines doesn't say either way. I'm happy to switch the file to no SP after the typename if that's the project preference. It could be argued that a cast that turns a void * to a pointer to another type can go, as Felipe noted, but I think that is better done in a separate patch, perhaps as a follow-up to this small stylistic clean-ups. I said it could be argued above, because I am on the fence on that change. If this were not using a type gpointer, whose point is to hide what the actual implementation of that type is, but a plain vanilla void *, then I would not have any doubt. But it feels wrong to look behind that deliberate gpointer abstraction and take advantage of the knowledge that it happens to be implemented as void * (and if we do not start from that knowledge, losing the cast is a wrong change). To be honest, I'm on the fence myself. Let's just leave the original patch queued, and if the no SP is preferable, I can do that as a separate patch. -John PS Sorry about the repeat message Junio. I forgot to CC the list. -- 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: Ubuntu may break Git upstream translations
2013/12/10 Dimitri John Ledkov dimitri.led...@canonical.com: Hello all, Ubuntu is a distribution which does have a wide variety of users. Typically users use stable releases, or even LTS releases (every 2 years). Given different schedules across all projects, naturally Ubuntu ships a snapshots across all packages available at the time. On the other hand our users and translators expect to be able continuously improve provide translations across a wide snapshot of packages. Therefore in the beginning of the Ubuntu project translations from all core packages (those that are in the main portion of the archive) were imported into the launchpad translation component. Ubuntu translation teams can update translations using the web interface, contributing from one string or all of them. All new translations done in launchpad, are done under permissive BSD license and are shared across the infrastructure, such that translators get helpful suggestions and don't have translate the same term over again (and/or different from how it's used across the operating system). These translations do not require one to know version control systems, upstream, mailing lists. But those translation updates are pushed out automatically to the users at point releases (or more often, if manually triggered). You can see the translation statistics for Ubuntu 12.04 LTS at [1] All of these translations are done in good faith. Or at times by frustrated users that cannot see something in their own language and can't take for an answer contribute upstream, wait for new release, wait for that to be packaged upgrade to new release to get them. Thank you for the quick response. I understand that 1. release of l10n things in separate package will help Ubuntu to improve l10n continuously, without recompiling the whole package (Git or others). This may save bandwidth when user upgrade. 2. bundle l10n things of hundreds of packages for one specific language in one package, will save disk usages a bit for users. Because user will only install the prefer language, won't install l10n things for other languages. That's OK. Naturally, maintenance cost of translations downstream is significant. And where possible we do try to redirect translators upstream. E.g. there are good translators links / cooperation to Debian (package descriptions, debconf question templates), d-i, GNOME, etc. In an ideal world there would be enough community developer to manual handle all new translations and redirect / introduce them to upstreams. Unfortunately that is not the case. And on behalf of the Ubuntu project, I do apologize for any inconvenience caused. But please do, try to understand the distribution perspective on the overall problem with localisation and internationalization. What makes Debian/Ubuntu outstanding? I believe it is the apt package management system. It's easy to write a debian package, and quilt patches are upstream-friendly. I mean using quilt commands (such quilt push, quilt pop, quilt refresh,...), patches can upgrade to the new upstream easily. But Ubuntu l10n things are not upstream friendly, substitute upstream l10n things instead of patching. The word patching here, not means using quilt patches. Since Ubuntu has a large database full of break down msg-ids, and each break down msg-id has its upstream translation and Ubuntu translation, your Ubuntu guys can invent your own patching system. E.g. Generate your new custom .po file based on a fresh upstream template using 3-way merge (prefer upstream change), and then substitute upstream with yours. -- Jiang Xin -- 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
Compiling git svn from source
Hi, I'm compiling git from source due to outdated binaries in Linux-flavour 'X'. I followed the installation instructions at git-scm.com, but somehow the sub-command svn (git svn) is not being installed. How us it that I would be able to install it from source? I have Googled for this, and the top result suggests to ask here. Here is how i'm compiling: $ make all $ sudo make install I'm hoping that I'm in the right place. Thank you, Avinash R -- 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 4/5] gitweb: Add a feature for adding more branch refs
On Thu, 2013-12-05 at 11:00 +0100, Krzesimir Nowak wrote: On Wed, 2013-12-04 at 19:06 +0100, Jakub Narębski wrote: On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com wrote: ++ +It is an error to specify a ref that does not pass git check-ref-format +scrutiny. Duplicated values are filtered. + Hmmm... 'snapshot' feature ignores invalid values, but in this case formerly valid compression schemes might get invalid via tightening %known_snapshot_formats, and we don't want existing config getting suddenly invalid. So, should I just ignore the invalid refs or treat them as errors? Ping, I'd like to know the answer for this question before I roll out another set of patches - there seem to be no agreement over it. Thanks! Cheers, -- Krzesimir Nowak Software Developer Endocode AG krzesi...@endocode.com -- Endocode AG, Johannisstraße 20, 10117 Berlin i...@endocode.com | www.endocode.com Vorstandsvorsitzender: Mirko Boehm Vorstände: Dr. Karl Beecher, Chris Kühl, Sebastian Sucker Aufsichtsratsvorsitzende: Jennifer Beecher Registergericht: Amtsgericht Charlottenburg - HRB 150748 B -- 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 v3 1/2] diff: move no-index detection to builtin/diff.c
Currently the --no-index option is parsed in diff_no_index(). Move the
detection if a no-index diff should be executed to builtin/diff.c, where
we can use it for executing diff_no_index() conditionally. This will
also allow us to execute other operations conditionally, which will be
done in the next patch.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Thanks to Junio, Torsten and Eric for comments on the previous round.
I've added this refactoring patch, to avoid the partial duplication of
the logic. I've also fixed the tests, that now use a sub-shell for
executing and fix the stray at the end of the test.
builtin/diff.c | 45 ++---
diff-no-index.c | 48 +++-
diff.h | 2 +-
3 files changed, 46 insertions(+), 49 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index adb93a9..7220b2c 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -257,7 +257,7 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
int blobs = 0, paths = 0;
const char *path = NULL;
struct blobinfo blob[2];
- int nongit;
+ int nongit, no_index = 0;
int result = 0;
/*
@@ -283,14 +283,53 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
* Other cases are errors.
*/
+ /* Were we asked to do --no-index explicitly? */
+ for (i = 1; i argc; i++) {
+ if (!strcmp(argv[i], --)) {
+ i++;
+ break;
+ }
+ if (!strcmp(argv[i], --no-index))
+ no_index = 1;
+ if (argv[i][0] != '-')
+ break;
+ }
+
prefix = setup_git_directory_gently(nongit);
+ /*
+* Treat git diff with at least one path outside of the
+* repo the same as if the command would have been executed
+* outside of a git repository. In this case it behaves
+* the same way as git diff --no-index a b, which acts
+* as a colourful diff replacement.
+*/
+ nongit |= (argc == i + 2) !(path_inside_repo(prefix, argv[i])
+ path_inside_repo(prefix, argv[i + 1]));
gitmodules_config();
git_config(git_diff_ui_config, NULL);
init_revisions(rev, prefix);
- /* If this is a no-index diff, just run it and exit there. */
- diff_no_index(rev, argc, argv, nongit, prefix);
+ if (no_index || nongit) {
+ if (argc != i + 2) {
+ if (!no_index) {
+ /*
+* There was no --no-index and there were not
two
+* paths. It is possible that the user intended
+* to do an inside-repository operation.
+*/
+ fprintf(stderr, Not a git repository\n);
+ fprintf(stderr,
+ To compare two paths outside a working
tree:\n);
+ }
+ /* Give the usage message for non-repository usage and
exit. */
+ usagef(git diff %s path path,
+ no_index ? --no-index : [--no-index]);
+
+ }
+ /* If this is a no-index diff, just run it and exit there. */
+ diff_no_index(rev, argc, argv, nongit, no_index, prefix);
+ }
/* Otherwise, we are doing the usual git diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
diff --git a/diff-no-index.c b/diff-no-index.c
index 00a8eef..78e3090 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -181,56 +181,14 @@ static int queue_diff(struct diff_options *o,
}
}
-void diff_no_index(struct rev_info *revs,
- int argc, const char **argv,
- int nongit, const char *prefix)
+int diff_no_index(struct rev_info *revs,
+ int argc, const char **argv,
+ int nongit, int no_index, const char *prefix)
{
int i, prefixlen;
- int no_index = 0;
unsigned deprecated_show_diff_q_option_used = 0;
const char *paths[2];
- /* Were we asked to do --no-index explicitly? */
- for (i = 1; i argc; i++) {
- if (!strcmp(argv[i], --)) {
- i++;
- break;
- }
- if (!strcmp(argv[i], --no-index))
- no_index = 1;
- if (argv[i][0] != '-')
- break;
- }
-
- if (!no_index !nongit) {
- /*
-* Inside a git repository, without --no-index. Only
-* when a path outside the repository is given,
-* e.g. git diff /var/tmp/[12], or git diff
-
Re: [PATCH v3 1/2] diff: move no-index detection to builtin/diff.c
(pruning cc list)
Hi,
Thomas Gummerer wrote:
Currently the --no-index option is parsed in diff_no_index(). Move the
detection if a no-index diff should be executed to builtin/diff.c
No functional change intended, I assume?
[...]
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -283,14 +283,53 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
[...]
prefix = setup_git_directory_gently(nongit);
+ /*
+ * Treat git diff with at least one path outside of the
+ * repo the same as if the command would have been executed
+ * outside of a git repository. In this case it behaves
+ * the same way as git diff --no-index a b, which acts
+ * as a colourful diff replacement.
+ */
+ nongit |= (argc == i + 2) !(path_inside_repo(prefix, argv[i])
+path_inside_repo(prefix, argv[i + 1]));
I would find this easier to read as
if (argc == i + 2
(!path_inside_repo(prefix, argv[i]) ||
!path_inside_repo(prefix, argv[i + 1])))
nongit = 1;
Or maybe using a different variable than 'nongit':
#define DIFF_NO_INDEX_EXPLICIT 1
#define DIFF_NO_INDEX_IMPLICIT 2
...
if (argc == i + 2 ...)
no_index = DIFF_NO_INDEX_IMPLICIT;
[...]
gitmodules_config();
git_config(git_diff_ui_config, NULL);
init_revisions(rev, prefix);
- /* If this is a no-index diff, just run it and exit there. */
- diff_no_index(rev, argc, argv, nongit, prefix);
+ if (no_index || nongit) {
[...]
+ }
Ok.
[...]
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -181,56 +181,14 @@ static int queue_diff(struct diff_options *o,
}
}
-void diff_no_index(struct rev_info *revs,
+int diff_no_index(struct rev_info *revs,
Why the change in return type?
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] diff: don't read index when --no-index is given
Thomas Gummerer wrote: --- a/builtin/diff.c +++ b/builtin/diff.c @@ -295,7 +295,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix) break; } - prefix = setup_git_directory_gently(nongit); + if (!no_index) + prefix = setup_git_directory_gently(nongit); What is the value of nongit in the no_index case? -- 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/2] diff: move no-index detection to builtin/diff.c
Jonathan Nieder jrnie...@gmail.com writes:
(pruning cc list)
Hi,
Thomas Gummerer wrote:
Currently the --no-index option is parsed in diff_no_index(). Move the
detection if a no-index diff should be executed to builtin/diff.c
No functional change intended, I assume?
Correct, I thought I'd split the refactoring from the functionality
changes.
[...]
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -283,14 +283,53 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
[...]
prefix = setup_git_directory_gently(nongit);
+/*
+ * Treat git diff with at least one path outside of the
+ * repo the same as if the command would have been executed
+ * outside of a git repository. In this case it behaves
+ * the same way as git diff --no-index a b, which acts
+ * as a colourful diff replacement.
+ */
+nongit |= (argc == i + 2) !(path_inside_repo(prefix, argv[i])
+ path_inside_repo(prefix, argv[i + 1]));
I would find this easier to read as
if (argc == i + 2
(!path_inside_repo(prefix, argv[i]) ||
!path_inside_repo(prefix, argv[i + 1])))
nongit = 1;
Or maybe using a different variable than 'nongit':
#define DIFF_NO_INDEX_EXPLICIT 1
#define DIFF_NO_INDEX_IMPLICIT 2
...
if (argc == i + 2 ...)
no_index = DIFF_NO_INDEX_IMPLICIT;
Thanks, that makes sense, will change in the re-roll.
[...]
gitmodules_config();
git_config(git_diff_ui_config, NULL);
init_revisions(rev, prefix);
-/* If this is a no-index diff, just run it and exit there. */
-diff_no_index(rev, argc, argv, nongit, prefix);
+if (no_index || nongit) {
[...]
+}
Ok.
[...]
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -181,56 +181,14 @@ static int queue_diff(struct diff_options *o,
}
}
-void diff_no_index(struct rev_info *revs,
+int diff_no_index(struct rev_info *revs,
Why the change in return type?
That was an oversight, no change is required. Will fix in the
re-roll. Thanks for taking the time for reviewing this.
Hope that helps,
Jonathan
--
Thomas
--
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] Additional git-archive tests
Nick Townsend nick.towns...@mac.com writes: In other words, are all these new tests expected to pass? Sorry about that - the first four tests do pass with 1.8.5, the last three tests do not currently pass. OK. So I do not think it is expected to accept tree object names with the HEAD:path style syntax, if the user expects a predictable and consistent result. The third step above attempts to make sure that you name a tree-ish that corresponds to the top-level of the project, i.e. with no path. That’s not quite right - paths do work from the root directory - see tests. I know that they work from the very top, but they _only_ happens to work from the very top. As I do not see the code is designed to compare the prefix (i.e. the subdirectory you are in) and the path that is tucked after the name of the top-level tree object with a colon (e.g. path in HEAD:path) and adjust these two accordingly, I do not think it was designed to deal with that at all. The code just assumes that the tree object corresponds to the top-level, and the adjustment is done solely by adding the prefix when limiting the output by paths. This observation *is* very right. Not designing to deal with that case may or may not be right, but that is a different issue. It was this very useful capability that I sought to add and generalized the code to do. What seems to be supported are: cd a git archive HEAD ;# archives HEAD:a tree cd a git archive HEAD -- b ;# archives a/b/ part of HEAD:a as b/ Specifically, it appears that HEAD:./b, HEAD:b etc. are not designed to work, at least to me. ... I am not saying that these should _not_ work, but it is unclear what it means to work. For example, what should this do? cd a git archive HEAD:./b $pathspec I think we can clear this up by documenting the cases and choosing sensible behaviour _for git-archive_ ie. what people might expect. I am afraid that this topic is not limited to git-archive; sensible behaviour _for git-archive_ will end up being far from sufficient. I would not be surprised if ls-tree shares the same issue, for example. If you had subdir/subsubdir/path (and other paths) tracked in your project, cd subdir git ls-tree HEAD:./subsubdir path is likely to have the same issue as cd subdir git archive HEAD:./subsubdir path I would think. Here is a suggestion: a. The pathspec is used as a selector to include things in the archive. it is applied after the cwd and treeish selection. That would mean that doing this in the top-level: git archive HEAD:subdir/subsubdir pathTAB will not auto-complete the pathname. In all other Git commands, vanilla pathspecs (at least the ones that do not use the magic escape hatch :/path, etc.) are relative to your current directory, and I do not think we want a single command to work in an inconsistent way with respect to that. b. The current working directory (if present) prefixes a path in the object if one is present. That is already done at a lower-level get_sha1_with_context(), I think. cd subdir git archive HEAD:./subsubdir will try to use tree subdir/subsubdir in the HEAD commit (but due to the prefix logic that is not preprared to use such a tree object, you will get current working directory is untracked error). c. The path in the object (if present) is prefixed by the cwd (if present) and used to select items for archiving. However the composite path so created *is not present* in the archive - ie. the leading components are stripped. (This is very useful behaviour for creating archives without leading paths) d. As currently the ―prefix option (not the prefix from setup_git_directory) is prepended to all entries in the archive. These correspond to the use cases that I have for git archive - extracting all or part of a multiple submodule tree into a tgz file, with or without leading directories. The extended SHA-1 expression HEAD:./b in the subdirectory a/ is interpreted by get_sha1_with_context_1() to be the name of the tree object at path a/b in the commit HEAD. Further, you are giving a pathspec while in a subdirectory a/ to the command. What should that pathspec be relative to? In a normal Git command, the pathspec always is relative to the current subdirectory, so, the way to learn about the tree object a/b/c in the HEAD while in subdirectory a/ would be: cd a git ls-tree HEAD b/c But what should the command line for archive to grab HEAD:a/b/c be? It feels wrong to say: cd a git archive HEAD:./b b/c It’s clear to me that if you are in a subdirectory, that is an implicit prefix on the ./b so you retrieve HEAD:a/b which then archives everything in b without the leading a/b. The pathspec is wrong (including the b) and this archive is empty. and it also feels wrong to say cd a git archive HEAD:./b c That looks fine to me given the rules suggested above. Also git-parse
Re: [PATCH 4/5] gitweb: Add a feature for adding more branch refs
Jakub Narębski jna...@gmail.com writes:
With multi-valued we won't be able to override earlier / more generic
settings... well, unless we add support for no-value, or empty-value
as clearer, i.e.
[gitweb]
extrabranchrefs = sandbox
extrabranchrefs
# orextrabranchrefs =
extrabranchrefs = wip other
resulting in ('wip', 'other').
Please don't, unless you are going to change the entire config
machinery (including config.c bits that are used by the rest of the
system) to follow such a convention to clear settings so far read.
++
+It is an error to specify a ref that does not pass git check-ref-format
+scrutiny. Duplicated values are filtered.
+
Hmmm... 'snapshot' feature ignores invalid values, but in this case
formerly valid compression schemes might get invalid via tightening
%known_snapshot_formats, and we don't want existing config getting
suddenly invalid.
Sorry, but what does check-ref-format have to do with formerly
valid compression scheme that suddenly gets invalidated???
--
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/2] diff: don't read index when --no-index is given
Jonathan Nieder jrnie...@gmail.com writes: Thomas Gummerer wrote: --- a/builtin/diff.c +++ b/builtin/diff.c @@ -295,7 +295,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix) break; } -prefix = setup_git_directory_gently(nongit); +if (!no_index) +prefix = setup_git_directory_gently(nongit); What is the value of nongit in the no_index case? In the no_index case it doesn't matter, since no_index is always checked first. The only other place where it is used, when no_index is set is after diff_no_index, which can't be reached if no_index is set. I could initialize nongit to 0, but I don't think that would change anything. I've also seen that the no_index and nongit parameters to diff_no_index are not needed anymore, and will remove them in the re-roll therefore. I'll wait to see if there are any more comments and then send a re-roll. Thanks! -- Thomas -- 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: Compiling git svn from source
Hi, avinash r wrote: I followed the installation instructions at git-scm.com, but somehow the sub-command svn (git svn) is not being installed. [...] Here is how i'm compiling: $ make all $ sudo make install What is the content of config.mak? Is there a file named config.mak.autogen? What is the output of git help -a | grep svn? Curious, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setting file timestamps to commit time (git-checkout)
Dominik Vogt v...@linux.vnet.ibm.com writes:
The second best approach I could think of is to stamp files with the
timestamp of the last commit that touched that, but I guess that is
not a cheap operation either.
I'm using this script for this:
#!/bin/sh
git log --name-only --format=format:%n%ct -- $@ |
perl -e 'my $do_date = 0; chomp(my $cdup = `git rev-parse --show-cdup`);
while () {
chomp;
if ($do_date) {
next if ($_ eq );
die Unexpected $_\n unless /^[0-9]+$/;
$d = $_;
$do_date = 0;
} elsif ($_ eq ) {
$do_date = 1;
} elsif (!defined($seen{$_})) {
$seen{$_} = 1;
utime $d, $d, $cdup$_;
}
}'
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: [PATCH 4/5] gitweb: Add a feature for adding more branch refs
On Tue, Dec 10, 2013 at 7:54 PM, Junio C Hamano gits...@pobox.com wrote:
Jakub Narębski jna...@gmail.com writes:
With multi-valued we won't be able to override earlier / more generic
settings... well, unless we add support for no-value, or empty-value
as clearer, i.e.
[gitweb]
extrabranchrefs = sandbox
extrabranchrefs
# orextrabranchrefs =
extrabranchrefs = wip other
resulting in ('wip', 'other').
Please don't, unless you are going to change the entire config
machinery (including config.c bits that are used by the rest of the
system) to follow such a convention to clear settings so far read.
Right. Also I haven't noticed that gitweb already uses some
multi-valued config variables, though not for %features.
Please disregard this.
++
+It is an error to specify a ref that does not pass git check-ref-format
+scrutiny. Duplicated values are filtered.
+
Hmmm... 'snapshot' feature ignores invalid values, but in this case
formerly valid compression schemes might get invalid via tightening
%known_snapshot_formats, and we don't want existing config getting
suddenly invalid.
Sorry, but what does check-ref-format have to do with formerly
valid compression scheme that suddenly gets invalidated???
What I started to write was that 'snapshot' feature ignores invalid
values, but halfway through writing it out I have noticed that the
situation is really different.
In 'snapshot' case one can have formerly valid per-repository config,
made invalid by gitweb admin tightening %known_snapshot_formats
(for example removing some compression format due to bug). We
do not want for repository to stop being displayed because of something
that is outside control of repository owner.
In 'check-ref-format' feature we have ref either valid or not. This does
not depend on external factors. Something that is valid ref would
remain valid ref.
So 'snaphot' being forgiving doesn't mean that 'check-ref-format'
should be forgiving.
--
Jakub Narebski
--
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: Refspec wildcards for remotes require trailing slash
Monte Goulding mo...@sweattechnologies.com writes: Before I go ahead and look at what needs to be done for a patch I thought it would be polite to ask if there is any reasoning behind the trailing slash rule that I'm missing? Or if you are interested in changing this behavior at all. The log messages of the two commits you cited in your message says that refs/a/b/* should not match refs/a/b1, but the old code mistakenly allowed to. As long that fix is not broken, allowing refs/a/b* to match refs/a/b1 is OK, I would think. But it is debatable if such a change should allow refs/a/b* to match refs/a/b/2. Arguments can be made in both ways, and my knee-jerk reaction is it shouldn't. -- 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: Unexpected cherry-pick behaviour
Paulo Matos pa...@matos-sorge.com writes: Note how there are changes that are not part of the cherry-picked patch outside of the conflicting zone. This is trouble some because it means that when I go in to fix a patch and look only at the conflicting zone, I will have code outside the zone, that are _not_ part of the patch modified as well. My suspicion (I am too lazy to try it myself ;-) is that your addition of a line myport_hook() was done to a section of code that was modified between the original you added the line to and the target you are trying to cherry-pick your change (that will inevitably cause conflicts and you cannot avoid that), and the post-processing done to make the three-way merge result more readable are ejecting common changes out of the conflicted region. Perhaps immediately after cherry-pick stopped and asked your help to resolve the conflicts, running $ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c and looking at the file again may show you what is going on better. -- 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 4/5] gitweb: Add a feature for adding more branch refs
Jakub Narębski jna...@gmail.com writes: So 'snaphot' being forgiving doesn't mean that 'check-ref-format' should be forgiving. OK, thanks for clarifying. -- 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: Refspec wildcards for remotes require trailing slash
On 11/12/2013, at 6:14 AM, Junio C Hamano gits...@pobox.com wrote: But it is debatable if such a change should allow refs/a/b* to match refs/a/b/2. Arguments can be made in both ways, and my knee-jerk reaction is it shouldn't. Hmm.. for-each-ref doesn't match it but ls-remote does Sorry: forgot to CC the list -- 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: Compiling git svn from source
Hi Jonathan, I managed to get `git svn` installed using old school commands executed before the commands I mentioned. $ make configure $ ./configure I wrote before: $ make all $ sudo make install thanks for asking about the config. Jonathan Nieder wrote: What is the content of config.mak? Is there a file named config.mak.autogen? What is the output of git help -a | grep svn? Curious, Jonathan but running the command, $ git svn init --username=username http://mydomain.com/myrepo causes the command to fail with the following error: Can't locate SVN/Core.pm in @INC (@INC contains: /usr/local/share/perl/5.14.2 /etc/perl /usr/local/lib/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/local/share/perl/5.14.2/Git/SVN/Utils.pm line 6. BEGIN failed--compilation aborted at /usr/local/share/perl/5.14.2/Git/SVN/Utils.pm line 6. Compilation failed in require at /usr/local/share/perl/5.14.2/Git/SVN.pm line 33. BEGIN failed--compilation aborted at /usr/local/share/perl/5.14.2/Git/SVN.pm line 33. Compilation failed in require at /usr/local/libexec/git-core/git-svn line 25. BEGIN failed--compilation aborted at /usr/local/libexec/git-core/git-svn line 25. I'm using the version 1.8.5.1. -- Avinash R -- 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 Benchmark
Hi list! There is a benchmark on the Git website [1]. Unfortunately it lacks (in my opinion substantial) information about what Git and what SVN version has been used. Can anyone give me that information? Is there any chance that I can run the benchmarks myself? Thanks in advance, Winnie [1] http://www.git-scm.com/about/small-and-fast -- 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: Compiling git svn from source
On Wed, Dec 11, 2013 at 01:54:26AM +0530, avinash r wrote: but running the command, $ git svn init --username=username http://mydomain.com/myrepo causes the command to fail with the following error: Can't locate SVN/Core.pm in @INC (@INC contains: /usr/local/share/perl/5.14.2 /etc/perl /usr/local/lib/perl/5.14.2 [...] git-svn relies on having subversion's own perl libraries installed by the system. If you are on a debian/ubuntu-based system, apt-get install libsvn-perl should do it; I don't know the package-name offhand for other systems. -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 1/4] subtree: support split --rejoin --squash
Matthew Ogilvie mmogilvi_...@miniinfo.net writes: Allow using --squash with git subtree split --rejoin. It will still split off (and save to --branch) the complete subtree history, but the merge done for the --rejoin will be merging a squashed representation of the new subtree commits, instead of the commits themselves (similar to how git subtree merge --squash works). Signed-off-by: Matthew Ogilvie mmogilvi_...@miniinfo.net --- I can think of a couple of possible objections to this patch. Are these (or any others) worth fixing? 1. Perhaps someone want the saved subtree (--branch) to have a squashed representation as well, as an option? Maybe we need two different --squash options? Something like --rejoin-squash? 2. It could definitely use some automated tests. In fact, pre-existing --squash functionality is hardly tested at all, either. See patch 4 comments for a script I use to help with mostly-manual testing. As I am totally uninterested in git subtree (sorry!), I'll queue these three patches as-is so that others who are interested and motivated to work on polishing it can take a look at them more easily. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Benchmark
On Tue, Dec 10, 2013 at 09:54:06PM +0100, Winniehell wrote: There is a benchmark on the Git website [1]. Unfortunately it lacks (in my opinion substantial) information about what Git and what SVN version has been used. Can anyone give me that information? Is there any chance that I can run the benchmarks myself? [1] http://www.git-scm.com/about/small-and-fast I believe those numbers were all run by Scott (cc'd), and are probably pretty old at this point. If you want to design and run a more modern benchmark, I'm sure we'd all be interested to see the results on this list. -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: Setting file timestamps to commit time (git-checkout)
Dominik Vogt wrote: How does git-new-workdir cope with rebasing (e.g. you have the same branch checked out in two working trees and rebase -i it in one of them)? Generally you don't have the same branch checked out in two working trees. I tend to use git checkout --detach to not have *any* branch checked out in most working trees, though that comes with its own set of problems since the HEAD reflog is not shared. Is it really a working option? Yes, modulo the two warnings above. ;-) If someone has time to work on it, the threads http://thread.gmane.org/gmane.comp.version-control.git/150559 http://thread.gmane.org/gmane.comp.version-control.git/182821 describe one way to make those caveats go away. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setting file timestamps to commit time (git-checkout)
Duy Nguyen wrote: I wonder if we could promote multiple worktree from a hack to a supported feature. What I have in mind is when you clone --separate-worktree it would create a .git file that describes separate worktree: gitbasedir: /path/to/the/original/.git name: foo HEAD, index and logs/HEAD would be stored in /path/to/the/original/.git/worktrees/foo/. I like this idea a lot. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
static variables
This is probably a naive question, but: there are quite a lot of static
variables in the git code where it's really unnecessary. Is that just a
historical artifact, or is there some reason to prefer them? I'm working
on a patch that will introduce threading, so naturally I'm on the lookout
for static variables. In general, can I get rid of static variables where
it seems straightforward to do so?
As an example, here's an excerpt from symlnks.c. In addition to being
static, if I'm reading this right, it appears that the 'removal' variable
is used before it's initialized:
static struct removal_def {
char path[PATH_MAX];
int len;
} removal;
static void do_remove_scheduled_dirs(int new_len)
{
while (removal.len new_len) {
removal.path[removal.len] = '\0';
if (rmdir(removal.path))
break;
do {
removal.len--;
} while (removal.len new_len
removal.path[removal.len] != '/');
}
removal.len = new_len;
}
void schedule_dir_for_removal(const char *name, int len)
{
int match_len, last_slash, i, previous_slash;
match_len = last_slash = i =
longest_path_match(name, len, removal.path, removal.len,
previous_slash);
/* Find last slash inside 'name' */
while (i len) {
if (name[i] == '/')
last_slash = i;
i++;
}
/*
* If we are about to go down the directory tree, we check if
* we must first go upwards the tree, such that we then can
* remove possible empty directories as we go upwards.
*/
if (match_len last_slash match_len removal.len)
do_remove_scheduled_dirs(match_len);
/*
* If we go deeper down the directory tree, we only need to
* save the new path components as we go down.
*/
if (match_len last_slash) {
memcpy(removal.path[match_len], name[match_len],
last_slash - match_len);
removal.len = last_slash;
}
}
void remove_scheduled_dirs(void)
{
do_remove_scheduled_dirs(0);
}
EOF
Thanks,
Stefan
--
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
My Dear Beloved in Christ,
My Dear Beloved in Christ, My Message is attached, From Sister Aicha Ameld MY MESSAGE IS ATTACHED, FROM SISTER AICHA AMELD,.doc Description: MS-Word document
Re: Setting file timestamps to commit time (git-checkout)
On 10 December 2013 00:35, Dominik Vogt v...@linux.vnet.ibm.com wrote: that sounds awfully expensive, and really out of the scope of an RCS. The second best approach I could think of is to stamp files with the timestamp of the last commit that touched that, but I guess that is not a cheap operation either. You can already do this with a very small third-party script: https://github.com/cnst/git-tools/blob/master/git-restore-mtime-core 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: static variables
Stefan Zager wrote:
This is probably a naive question, but: there are quite a lot of static
variables in the git code where it's really unnecessary. Is that just a
historical artifact, or is there some reason to prefer them?
Sometimes it's for convenience. Other times it's to work around C89's
requirement that initializers can't include pointers to automatic
variables, so when using parse_options, old commands tend to use
statics for the variables initialized by options. (Since then, git
has stopped following that so rigidly, which is probably a good
thing.)
Worse, some functions have static buffers when they need a large
buffer and want to avoid too much allocation churn. As a general
rule, historically very little of git's code (mostly pack related)
needed to be usable with threads, though of course it would be
excellent to fix more code to be thread-safe.
As an example, here's an excerpt from symlnks.c. In addition to being
static, if I'm reading this right, it appears that the 'removal' variable
is used before it's initialized:
statics are allocated from the .bss section, where they are zeroed
automatically.
static struct removal_def {
char path[PATH_MAX];
int len;
} removal;
Plumbing this through the call stack instead of using a static sounds
like a good idea. That would mean allocating the removal_def in
unpack-trees.c::check_updates, I think (see v1.6.3-rc0~147^2~16,
unlink_entry(): introduce schedule_dir_for_removal(), 2009-02-09 for
context). Then the loop could be divided into chunks that each use
their own removal_def or something.
Sometimes when git needs parallelism and threads don't work, it uses
fork + exec (aka run_command). Making the relevant functionality
thread-safe is generally much nicer, though.
Thanks and hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: static variables
Jonathan Nieder wrote: Stefan Zager wrote: This is probably a naive question, but: there are quite a lot of static variables in the git code where it's really unnecessary. Is that just a historical artifact, or is there some reason to prefer them? Sometimes it's for convenience. See for example path.c::git_path and mkpath. Threaded code uses a specialized thread-safe dialect of the usual C used in git. I wish I had better news to offer. -- 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
[BUG] echo HEAD | git cat-file --batch='' fails catastrophically
Observe: % echo HEAD | git cat-file --batch= fatal: object fde075cb72fc0773d8e8ca93d55a35d77bb6688b changed type!? Without the =, it works fine; with a string that has both %(objecttype) and %(objectsize), it's fine; but when you don't include both, it complains about one of the values that you did not mention having changed. jrnieder fingered v1.8.4-rc0~7^2~15 as the (likely?) culprit here. -- 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: Setting file timestamps to commit time (git-checkout)
On Tue, Dec 10, 2013 at 08:02:29PM +0100, Andreas Schwab wrote: Dominik Vogt v...@linux.vnet.ibm.com writes: The second best approach I could think of is to stamp files with the timestamp of the last commit that touched that, but I guess that is not a cheap operation either. I'm using this script for this: [snip] Hm, that runs 18 s on the local Gcc repository. That's not as expensive as I would have thought, but definitely not suitable to run automatically on each checkout. I wonder if performance could be improved by integrating the script logic into the git-checkout code (activated by a command line option). On Tue, Dec 10, 2013 at 05:39:05PM -0800, Constantine A. Murenin wrote: You can already do this with a very small third-party script: https://github.com/cnst/git-tools/blob/master/git-restore-mtime-core That script just produces error messages for me. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany -- 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 v3 03/10] Introduce lookup_replace_object_extended() to pass flags
Currently, there is only one caller to lookup_replace_object()
that can benefit from passing it some flags, but we expect
that there could be more.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 873a6b5..563f85f 100644
--- a/cache.h
+++ b/cache.h
@@ -773,6 +773,12 @@ static inline const unsigned char
*lookup_replace_object(const unsigned char *sh
return sha1;
return do_lookup_replace_object(sha1);
}
+static inline const unsigned char *lookup_replace_object_extended(const
unsigned char *sha1, unsigned flag)
+{
+ if (! (flag LOOKUP_REPLACE_OBJECT))
+ return sha1;
+ return lookup_replace_object(sha1);
+}
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/sha1_file.c b/sha1_file.c
index 76e9f32..4fb2f17 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2591,8 +2591,7 @@ void *read_sha1_file_extended(const unsigned char *sha1,
void *data;
char *path;
const struct packed_git *p;
- const unsigned char *repl = (flag LOOKUP_REPLACE_OBJECT)
- ? lookup_replace_object(sha1) : sha1;
+ const unsigned char *repl = lookup_replace_object_extended(sha1, flag);
errno = 0;
data = read_object(repl, type, size);
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/10] Rename READ_SHA1_FILE_REPLACE flag to LOOKUP_REPLACE_OBJECT
The READ_SHA1_FILE_REPLACE flag is more related to using the
lookup_replace_object() function rather than the
read_sha1_file() function.
We also need such a flag to be used with sha1_object_info()
instead of read_sha1_file().
The name LOOKUP_REPLACE_OBJECT is therefore better for this
flag.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
cache.h | 4 ++--
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index ce377e1..873a6b5 100644
--- a/cache.h
+++ b/cache.h
@@ -760,11 +760,11 @@ int daemon_avoid_alias(const char *path);
int offset_1st_component(const char *path);
/* object replacement */
-#define READ_SHA1_FILE_REPLACE 1
+#define LOOKUP_REPLACE_OBJECT 1
extern void *read_sha1_file_extended(const unsigned char *sha1, enum
object_type *type, unsigned long *size, unsigned flag);
static inline void *read_sha1_file(const unsigned char *sha1, enum object_type
*type, unsigned long *size)
{
- return read_sha1_file_extended(sha1, type, size,
READ_SHA1_FILE_REPLACE);
+ return read_sha1_file_extended(sha1, type, size, LOOKUP_REPLACE_OBJECT);
}
extern const unsigned char *do_lookup_replace_object(const unsigned char
*sha1);
static inline const unsigned char *lookup_replace_object(const unsigned char
*sha1)
diff --git a/sha1_file.c b/sha1_file.c
index daacc0c..76e9f32 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2591,7 +2591,7 @@ void *read_sha1_file_extended(const unsigned char *sha1,
void *data;
char *path;
const struct packed_git *p;
- const unsigned char *repl = (flag READ_SHA1_FILE_REPLACE)
+ const unsigned char *repl = (flag LOOKUP_REPLACE_OBJECT)
? lookup_replace_object(sha1) : sha1;
errno = 0;
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/10] replace_object: don't check read_replace_refs twice
Since ecef (inline lookup_replace_object() calls, May 15 2011) the read_replace_refs global variable is checked twice, once in lookup_replace_object() and once again in do_lookup_replace_object(). As do_lookup_replace_object() is called only from lookup_replace_object(), we can remove the check in do_lookup_replace_object(). Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- replace_object.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/replace_object.c b/replace_object.c index d0b1548..cdcaf8c 100644 --- a/replace_object.c +++ b/replace_object.c @@ -97,9 +97,6 @@ const unsigned char *do_lookup_replace_object(const unsigned char *sha1) int pos, depth = MAXREPLACEDEPTH; const unsigned char *cur = sha1; - if (!read_replace_refs) - return sha1; - prepare_replace_object(); /* Try to recursively replace the object */ -- 1.8.5.1.102.g090758b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/10] teach replace objects to sha1_object_info_extended()
Here is version 3 of a patch series to improve the way sha1_object_info_extended() behaves when it is passed a replaced object. The idea is to add a flags argument to it in the same way as what has been done to read_sha1_file(). This patch series was inspired by a sub thread in this discussion: http://thread.gmane.org/gmane.comp.version-control.git/238118 The only change compared to version 2 is that a few more tests have been added to patch 8/10, as suggested by Eric Sunchine. As in the previous version, patches 7/10, 8/10, 9/10 and 10/10 add a new --format option to list replace refs. 'short' (which is the default), 'medium' and 'full' formats are supported. This could be considered another patch series, but it is also related, because it uses sha1_object_info() and it fixes its use in builtin/replace.c by unsetting the global variable read_replace_refs in cmd_replace(). Christian Couder (10): Rename READ_SHA1_FILE_REPLACE flag to LOOKUP_REPLACE_OBJECT replace_object: don't check read_replace_refs twice Introduce lookup_replace_object_extended() to pass flags Add an unsigned flags parameter to sha1_object_info_extended() t6050: show that git cat-file --batch fails with replace objects sha1_file: perform object replacement in sha1_object_info_extended() builtin/replace: teach listing using short, medium or full formats t6050: add tests for listing with --format builtin/replace: unset read_replace_refs Documentation/git-replace: describe --format option Documentation/git-replace.txt | 19 - builtin/cat-file.c| 2 +- builtin/replace.c | 63 ++- cache.h | 12 ++--- replace_object.c | 3 --- sha1_file.c | 20 +++--- streaming.c | 2 +- t/t6050-replace.sh| 42 + 8 files changed, 137 insertions(+), 26 deletions(-) -- 1.8.5.1.102.g090758b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/10] builtin/replace: unset read_replace_refs
When checking to see if some objects are of the same type
and when displaying the type of objects, git replace uses
the sha1_object_info() function.
Unfortunately this function by default respects replace
refs, so instead of the type of a replaced object, it
gives the type of the replacement object which might
be different.
To fix this bug, and because git replace should work at a
level before replacement takes place, let's unset the
read_replace_refs global variable at the beginning of
cmd_replace().
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 2 ++
t/t6050-replace.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 9f3619a..1672870 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -174,6 +174,8 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
OPT_END()
};
+ read_replace_refs = 0;
+
argc = parse_options(argc, argv, prefix, options, git_replace_usage, 0);
if (list delete)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index e1cc3b8..d0c62f7 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -306,7 +306,7 @@ test_expect_success 'test --format medium' '
test_cmp expected actual
'
-test_expect_failure 'test --format full' '
+test_expect_success 'test --format full' '
{
echo $H1 (commit) - $BLOB (blob)
echo $BLOB (blob) - $REPLACED (blob)
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/10] Add an unsigned flags parameter to sha1_object_info_extended()
This parameter is not used yet, but it will be used to tell
sha1_object_info_extended() if it should perform object
replacement or not.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c| 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index b2ca775..b15c064 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -238,7 +238,7 @@ static int batch_one_object(const char *obj_name, struct
batch_options *opt,
return 0;
}
- if (sha1_object_info_extended(data-sha1, data-info) 0) {
+ if (sha1_object_info_extended(data-sha1, data-info,
LOOKUP_REPLACE_OBJECT) 0) {
printf(%s missing\n, obj_name);
fflush(stdout);
return 0;
diff --git a/cache.h b/cache.h
index 563f85f..701e42c 100644
--- a/cache.h
+++ b/cache.h
@@ -1104,7 +1104,7 @@ struct object_info {
} packed;
} u;
};
-extern int sha1_object_info_extended(const unsigned char *, struct object_info
*);
+extern int sha1_object_info_extended(const unsigned char *, struct object_info
*, unsigned flags);
/* Dumb servers support */
extern int update_server_info(int);
diff --git a/sha1_file.c b/sha1_file.c
index 4fb2f17..482037e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2443,7 +2443,7 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
return 0;
}
-int sha1_object_info_extended(const unsigned char *sha1, struct object_info
*oi)
+int sha1_object_info_extended(const unsigned char *sha1, struct object_info
*oi, unsigned flags)
{
struct cached_object *co;
struct pack_entry e;
@@ -2477,7 +2477,7 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi)
rtype = packed_object_info(e.p, e.offset, oi);
if (rtype 0) {
mark_bad_packed_object(e.p, sha1);
- return sha1_object_info_extended(sha1, oi);
+ return sha1_object_info_extended(sha1, oi, 0);
} else if (in_delta_base_cache(e.p, e.offset)) {
oi-whence = OI_DBCACHED;
} else {
@@ -2499,7 +2499,7 @@ int sha1_object_info(const unsigned char *sha1, unsigned
long *sizep)
oi.typep = type;
oi.sizep = sizep;
- if (sha1_object_info_extended(sha1, oi) 0)
+ if (sha1_object_info_extended(sha1, oi, LOOKUP_REPLACE_OBJECT) 0)
return -1;
return type;
}
diff --git a/streaming.c b/streaming.c
index debe904..9659f18 100644
--- a/streaming.c
+++ b/streaming.c
@@ -113,7 +113,7 @@ static enum input_source istream_source(const unsigned char
*sha1,
oi-typep = type;
oi-sizep = size;
- status = sha1_object_info_extended(sha1, oi);
+ status = sha1_object_info_extended(sha1, oi, 0);
if (status 0)
return stream_error;
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/10] t6050: show that git cat-file --batch fails with replace objects
When --batch is passed to git cat-file, the sha1_object_info_extended() function is used to get information about the objects passed to git cat-file. Unfortunately sha1_object_info_extended() doesn't take care of object replacement properly, so it will often fail with a message like this: $ echo a3fb2e1845a1aaf129b7975048973414dc172173 | git cat-file --batch a3fb2e1845a1aaf129b7975048973414dc172173 commit 231 fatal: object a3fb2e1845a1aaf129b7975048973414dc172173 change size!? The goal of this patch is to show this breakage. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- t/t6050-replace.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh index 7d47984..b90dbdc 100755 --- a/t/t6050-replace.sh +++ b/t/t6050-replace.sh @@ -276,6 +276,11 @@ test_expect_success '-f option bypasses the type check' ' git replace -f HEAD^ $BLOB ' +test_expect_failure 'git cat-file --batch works on replace objects' ' + git replace | grep $PARA3 + echo $PARA3 | git cat-file --batch +' + test_expect_success 'replace ref cleanup' ' test -n $(git replace) git replace -d $(git replace) -- 1.8.5.1.102.g090758b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/10] sha1_file: perform object replacement in sha1_object_info_extended()
sha1_object_info_extended() should perform object replacement
if it is needed.
The simplest way to do that is to make it call
lookup_replace_object_extended().
And now its unsigned flags parameter is used as it is passed
to lookup_replace_object_extended().
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
sha1_file.c| 13 +++--
t/t6050-replace.sh | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 482037e..ee224e4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2448,8 +2448,9 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi,
struct cached_object *co;
struct pack_entry e;
int rtype;
+ const unsigned char *real = lookup_replace_object_extended(sha1, flags);
- co = find_cached_object(sha1);
+ co = find_cached_object(real);
if (co) {
if (oi-typep)
*(oi-typep) = co-type;
@@ -2461,23 +2462,23 @@ int sha1_object_info_extended(const unsigned char
*sha1, struct object_info *oi,
return 0;
}
- if (!find_pack_entry(sha1, e)) {
+ if (!find_pack_entry(real, e)) {
/* Most likely it's a loose object. */
- if (!sha1_loose_object_info(sha1, oi)) {
+ if (!sha1_loose_object_info(real, oi)) {
oi-whence = OI_LOOSE;
return 0;
}
/* Not a loose object; someone else may have just packed it. */
reprepare_packed_git();
- if (!find_pack_entry(sha1, e))
+ if (!find_pack_entry(real, e))
return -1;
}
rtype = packed_object_info(e.p, e.offset, oi);
if (rtype 0) {
- mark_bad_packed_object(e.p, sha1);
- return sha1_object_info_extended(sha1, oi, 0);
+ mark_bad_packed_object(e.p, real);
+ return sha1_object_info_extended(real, oi, 0);
} else if (in_delta_base_cache(e.p, e.offset)) {
oi-whence = OI_DBCACHED;
} else {
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index b90dbdc..bb785ec 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,7 +276,7 @@ test_expect_success '-f option bypasses the type check' '
git replace -f HEAD^ $BLOB
'
-test_expect_failure 'git cat-file --batch works on replace objects' '
+test_expect_success 'git cat-file --batch works on replace objects' '
git replace | grep $PARA3
echo $PARA3 | git cat-file --batch
'
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/10] t6050: add tests for listing with --format
This patch adds tests for git replace -l --format=fmt.
'short', 'medium' and 'full' are the only allowed values
for fmt.
'short' is the same as with no --format option.
Tests for 'medium' and 'full' are the most needed.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 37 +
1 file changed, 37 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index bb785ec..e1cc3b8 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -281,6 +281,43 @@ test_expect_success 'git cat-file --batch works on replace
objects' '
echo $PARA3 | git cat-file --batch
'
+test_expect_success 'test --format bogus' '
+ test_must_fail git replace --format bogus /dev/null 21
+'
+
+test_expect_success 'test --format short' '
+ git replace --format=short actual
+ git replace expected
+ test_cmp expected actual
+'
+
+test_expect_success 'test --format medium' '
+ H1=$(git --no-replace-objects rev-parse HEAD~1)
+ HT=$(git --no-replace-objects rev-parse HEAD^{tree})
+ MYTAG=$(git --no-replace-objects rev-parse mytag)
+ {
+ echo $H1 - $BLOB
+ echo $BLOB - $REPLACED
+ echo $HT - $H1
+ echo $PARA3 - $S
+ echo $MYTAG - $HASH1
+ } | sort expected
+ git replace -l --format medium | sort actual
+ test_cmp expected actual
+'
+
+test_expect_failure 'test --format full' '
+ {
+ echo $H1 (commit) - $BLOB (blob)
+ echo $BLOB (blob) - $REPLACED (blob)
+ echo $HT (tree) - $H1 (commit)
+ echo $PARA3 (commit) - $S (commit)
+ echo $MYTAG (tag) - $HASH1 (commit)
+ } | sort expected
+ git replace --format=full | sort actual
+ test_cmp expected actual
+'
+
test_expect_success 'replace ref cleanup' '
test -n $(git replace)
git replace -d $(git replace)
--
1.8.5.1.102.g090758b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats
By default when listing replace refs, only the sha1 of the
replaced objects are shown.
In many cases, it is much nicer to be able to list all the
sha1 of the replaced objects along with the sha1 of the
replacment objects.
And in other cases it might be interesting to also show the
types of the replaced and replacement objects.
This patch introduce a new --format=fmt option where
fmt can be any of the following:
'short': this is the same as when no --format
option is used, that is only the sha1 of
the replaced objects are shown
'medium': this also lists the sha1 of the
replacement objects
'full': this shows the sha1 and the type of both
the replaced and the replacement objects
Some documentation and some tests will follow.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 61 ---
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index b1bd3ef..9f3619a 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -16,27 +16,65 @@
static const char * const git_replace_usage[] = {
N_(git replace [-f] object replacement),
N_(git replace -d object...),
- N_(git replace -l [pattern]),
+ N_(git replace [--format=format] [-l [pattern]]),
NULL
};
+enum repl_fmt { SHORT, MEDIUM, FULL };
+
+struct show_data {
+ const char *pattern;
+ enum repl_fmt fmt;
+};
+
static int show_reference(const char *refname, const unsigned char *sha1,
int flag, void *cb_data)
{
- const char *pattern = cb_data;
+ struct show_data *data = cb_data;
+
+ if (!fnmatch(data-pattern, refname, 0)) {
+ if (data-fmt == SHORT)
+ printf(%s\n, refname);
+ else if (data-fmt == MEDIUM)
+ printf(%s - %s\n, refname, sha1_to_hex(sha1));
+ else { /* data-fmt == FULL */
+ unsigned char object[20];
+ enum object_type obj_type, repl_type;
- if (!fnmatch(pattern, refname, 0))
- printf(%s\n, refname);
+ if (get_sha1(refname, object))
+ return error(Failed to resolve '%s' as a valid
ref., refname);
+
+ obj_type = sha1_object_info(object, NULL);
+ repl_type = sha1_object_info(sha1, NULL);
+
+ printf(%s (%s) - %s (%s)\n, refname,
typename(obj_type),
+ sha1_to_hex(sha1), typename(repl_type));
+ }
+ }
return 0;
}
-static int list_replace_refs(const char *pattern)
+static int list_replace_refs(const char *pattern, const char *format)
{
+ struct show_data data;
+
if (pattern == NULL)
pattern = *;
+ data.pattern = pattern;
+
+ if (format == NULL || *format == '\0' || !strcmp(format, short))
+ data.fmt = SHORT;
+ else if (!strcmp(format, medium))
+ data.fmt = MEDIUM;
+ else if (!strcmp(format, full))
+ data.fmt = FULL;
+ else
+ die(invalid replace format '%s'\n
+ valid formats are 'short', 'medium' and 'full'\n,
+ format);
- for_each_replace_ref(show_reference, (void *) pattern);
+ for_each_replace_ref(show_reference, (void *) data);
return 0;
}
@@ -127,10 +165,12 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
int cmd_replace(int argc, const char **argv, const char *prefix)
{
int list = 0, delete = 0, force = 0;
+ const char *format = NULL;
struct option options[] = {
OPT_BOOL('l', list, list, N_(list replace refs)),
OPT_BOOL('d', delete, delete, N_(delete replace refs)),
OPT_BOOL('f', force, force, N_(replace the ref if it
exists)),
+ OPT_STRING(0, format, format, N_(format), N_(use this
format)),
OPT_END()
};
@@ -140,6 +180,10 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
usage_msg_opt(-l and -d cannot be used together,
git_replace_usage, options);
+ if (format delete)
+ usage_msg_opt(--format and -d cannot be used together,
+ git_replace_usage, options);
+
if (force (list || delete))
usage_msg_opt(-f cannot be used with -d or -l,
git_replace_usage, options);
@@ -157,6 +201,9 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
if (argc != 2)
usage_msg_opt(bad number of arguments,
git_replace_usage, options);
+ if (format)
+
[PATCH v3 10/10] Documentation/git-replace: describe --format option
Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index f373ab4..7a07828 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git replace' [-f] object replacement 'git replace' -d object... -'git replace' -l [pattern] +'git replace' [--format=format] [-l [pattern]] DESCRIPTION --- @@ -70,6 +70,23 @@ OPTIONS Typing git replace without arguments, also lists all replace refs. +--format=format:: + When listing, use the specified format, which can be one of + 'short', 'medium' and 'full'. When omitted, the format + defaults to 'short'. + +FORMATS +--- + +The following format are available: + +* 'short': + replaced sha1 +* 'medium': + replaced sha1 - replacement sha1 +* 'full' + replaced sha1 (replaced type) - replacement sha1 (replacement type) + CREATING REPLACEMENT OBJECTS -- 1.8.5.1.102.g090758b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
