Re: Feature Request for the Git Bundler
On Mon, 27 May 2013 16:11:06 +0430, Omid Mo'menzadeh omid.mnza...@gmail.com wrote: Dear Tomas, I was using your git bundler a few days ago, and it worked like a charm. But there is a problem out there, and that is most users of your bundler are people using an unstable internet connection. I downloaded the bundle, and 'git bundle verify' said it was OK, but it wasn't. My only way of knowing that was asking for someone to download it and give me a checksum, and it took a whole day for me. So it would be nice if you could add a chekcsum, md5, sha1 or anything, to the download page, so anyone can check the downloaded bundle easily. I think the real problem is that git bundle verify does not actually verify the contents. Maybe there is another command which can check the contents of a bundle for corruption? A added the git mailing list to CC, maybe someone there knows more. Note for readers on the mailing list: the bundler service Omid is referring to is the one that I host here: http://bundler.caurea.org. -- 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
Building git with NO_PERL=1 will install git-submodule, which depends on perl
Compare with git-instaweb which is replaced by as a small shell script which informs the user that the functionality is not implemented. I've only checked git-submodule, other commands may also have an undocumented dependency on perl. -- 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: Feature request: Allow extracting revisions into directories
On Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker fuz...@gmail.com wrote: Of course that is a possibility but it does not not feel right and is not intuitive. Adding this feature won't cause feature creep but would rather add an operation that makes sense in some scenarios and reduces the dependencies on other commands that might not be available on other platforms (If you care about that). I'd really like to see your reply to Sitaram's email regarding the many options that tar has. Sure, just teaching git-archive the equivalent of `|tar -x' probably isn't feature creep. But why stop there and not add some of the other options as well? After all, some might be equally useful in a different situation. So where do you stop? When you've completely merged tar into git? Also, this functionality is in full accordance with the Unix principle as it is a basic operation (put tree into files) and not something super special. That's what `git checkout` is for. And I would even argue that it's the better choice in your situation because it would delete files from /var/www/foo which you have deleted in your repo. git archive|tar wouldn't do that. -- 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] gitremote-helpers.txt: rename from git-remote-helpers.txt
On Thu, 31 Jan 2013 20:08:14 +, John Keeping j...@keeping.me.uk wrote:
This is the patch to rename it to gitremote-helpers.txt.
Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} | 6 +++---
It feels somewhat weird to have 'git-remote' but 'gitremote-helpers'.
--
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: How to identify the users?
On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan scottya...@gmail.com wrote: Hello everyone: The user info of git client (user name and email) is set by the users themselves, so , how to avoid userA pretend to be userB? Git server could authentication the user, but it do nothing about the user info of commit message. For example: There are 20 people of my team, and everyone can push to the public repository(git server), If I found some backdoor code in my project, and the commit record shows it was committed by userA, so I ask userA: why do you do this? but he told me: no, this is not my code, I have never committed such thing. and yes, everyone could change his user info to userA very easily . so... what should I do to avoid such situations? gitolite keeps a log of which SSH user pushed which commits. The smart-http backend does the same if you have reflog enabled on the server (see the ENVIRONMENT section in man git-http-backend). So unless someone can steal userA's credentials (http password, ssh key) you'll be able to detect who it really was. -- 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: [RFC] git rm -u
On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz lobbyjo...@gmail.com wrote: Hello everyone, I am thinking about implementing a feature but I would appreciate any feedback before I begin, because more experienced Git developers and users may see some major problem that I do not. Earlier today I deleted a file from a repository. I deleted it normally, not by using `git rm`. So when I looked at `git status` on my terminal it told me about the file no longer being there. In my sleepy state of mind I ran `git rm -u` without thinking about. I did this because I have a habit of using `git add -u`. I know `git rm` does not support that option, but I tried it anyways without thinking about it. When I came to my senses and realized that does not work I began to wonder if `git rm -u` should exist. If any deleted, tracked files are not part of the index to commit then `git rm -u` would add that change to the index. This would save users the effort of having to type out `git rm filename`, and could be useful when a user is deleting multiple files. Does this sound like a reasonable, useful feature to Git? Or is there already a way to accomplish this which I have missed out of ignorance? Any thoughts and feedback would be greatly appreciated. Does `git add -A` do what you want? -- 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] fix some clang warnings
On Wed, 16 Jan 2013 09:50:57 -0800, Jeff King p...@peff.net wrote: However, clang also defines __GNUC__, [...] http://sourceforge.net/p/predef/wiki/Compilers/ Notice that the meaning of the __GNUC__ macro has changed subtly over the years, from identifying the GNU C/C++ compiler to identifying any compiler that implements the GNU compiler extensions (...). For example, the Intel C++ on Linux also defines these macros from version 8.1 (...). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Find the starting point of a local branch
On Mon, 24 Dec 2012 12:28:45 +0700, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Mon, Dec 24, 2012 at 11:09 AM, Seth Robertson in-gitv...@baka.org wrote: In message 20121224035825.GA17203@zuhnb712, Woody Wu writes: How can I find out what's the staring reference point (a commit number or tag name) of a locally created branch? I can use gitk to find out it but this method is slow, I think there might be a command line to do it quickly. The answer is more complex than you probably suspected. Technically, `git log --oneline mybranch | tail -n 1` will tell you the starting point of any branch. But...I'm sure that isn't what you want to know. You want to know what commit was I at when I typed `git branch mybranch`? The problem is git doesn't record this information and doesn't have the slightest clue. Maybe we should store this information. reflog is a perfect place for this, I think. If this information is reliably available, git rebase can be told to rebase my whole branch instead of my choosing the base commit for it. What's the starting point of the branch if I type: git branch foo commit-ish? -- 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 log reliability
On Mon, 17 Dec 2012 14:56:17 +0530, Prasad Karmarkar prasad.s.karmar...@gmail.com wrote: Hi , I have been hearing from my Release Management that git log is not reliable. Is it so ? Is there a known instance where Git log has missed out on commits ? Any information about this would be really helpful Are you talking about git skipping commits due to history simplification (read the corresponding section in the git-log man page)? Also, what for does your release management use git log? Maybe there is a better way to do what you need to do. -- 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: How to specify remote branch correctly
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill andrew.ard...@gmail.com wrote: On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? Correct. Your working directory (files) switch over to whatever your local branch 'foo' points to, and your HEAD is updated to point to your local branch 'foo'. Unless something goes wrong/you have conflicting files/uncommitted changes etc. 'git checkout foo' has special meaning if a local branch with that name doesn't exist but there is a remote branch with that name. In that case it's equivalent to: git checkout -t -b foo origin/foo. Because that's what people usually want. -- 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: How to specify remote branch correctly
On Mon, 17 Dec 2012 07:02:46 +, Woody Wu narkewo...@gmail.com wrote:
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote:
'git checkout foo' has special meaning if a local branch with that
name doesn't exist but there is a remote branch with that name. In
that case it's equivalent to: git checkout -t -b foo origin/foo.
Because that's what people usually want.
I think this is what exactly happened to me in the first time I got the
'foo'. One new thing to me is the '-t'. I am not sure wether the '-t'
was used or not in the background. How do I check the 'upstream'
relationships? Is there any file under .git recoreded that kind of
information?
Yes, that information is recorded in a file somewhere in .git. However, for
most users it's irrelevant which file it is. Git has commands to access this
information. Try one of these:
git branch -vv
git remote show origin
git rev-parse --abbrev-ref --symbolic-full-name @{u}
--
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: Python extension commands in git - request for policy change
On Wed, 12 Dec 2012 05:39:43 +0530, Sitaram Chamarty sitar...@gmail.com wrote:
Does lua have os.putenv() yet? The inability to even *set* an env var
before calling something else was a killer for me when I last tried
it.
If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
since I used Lua, but it would be something like this:
void L_putenv(lua_State *L) {
putenv(lua_tostring(L, 1));
}
and then somewhere during setup:
lua_register(L, putenv, L_putenv);
--
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: Python extension commands in git - request for policy change
On Wed, 12 Dec 2012 08:50:27 +0700, Nguyen Thai Ngoc Duy pclo...@gmail.com
wrote:
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
tomas.carne...@gmail.com wrote:
If it doesn't, it would be trivial to add. It's a one-liner. It's been a
while
since I used Lua, but it would be something like this:
void L_putenv(lua_State *L) {
putenv(lua_tostring(L, 1));
}
and then somewhere during setup:
lua_register(L, putenv, L_putenv);
I should have done my homework before asking, but well.. is there any
way to automate this? If we use lua for writing builtin commands,
we'll need to export a lot of C functions and writing wrappers like
this is boring and time consuming. Also, assume I export fn(char*,int)
to Lua, then I change the prototype to fn(char*, char*), can Lua spot
all the call sites at compile time (or something) so I can update
them?
A Patrick mentioned in an earlier email, there is luaposix which includes lots
of these functions [1]. There may be tools which generate these bindings
automatically, but I'm not aware of any. Likewise, I'm not aware of any static
analyzer which would be required to spot changes in the prototypes (though you
could cover some(most?) of it through tests). The last time I seriously used
Lua and its C bindings was many years ago, so I am not the best person to
answer these questions.
[1]: http://luaposix.github.com/luaposix/docs/index.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit gone after merge - how to debug?
On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar igor.lau...@gmail.com wrote: git log file modified by commit - commit NOT shown in file history any more and file does not have this change does `git log --full-history file modified by commit` show the commit? -- 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: using multiple version of git simultaneously
On Sat, 17 Nov 2012 20:25:21 +0600, arif aft...@gmail.com wrote: I'm trying to use different version of git simultaneously. So how can i append some suffix (like --program-suffix=git1.8) so that i can distinguish between different versions. Install each version into its own prefix (~/git/1.8.0/, ~/git/1.7.0/ etc). -- 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: 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: orphan blob or what?
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: Like commit -a, but...
On Mon, 05 Nov 2012 21:56:28 +0100, Andreas Krey a.k...@gmx.de wrote: On Mon, 05 Nov 2012 21:29:48 +, Andreas Krey wrote: ... But still I'd like to know if there is a cleaner solution, esp. with respect to the index. Actually, it seems commit -m 'index' commit -a -m 'worktree' ...push git reset HEAD^ git reset --soft HEAD^ might do the index trick. But is there a direct way to convert the current working tree into a tree object? PARENT=$(git rev-parse HEAD) TREE=$(git write-tree) COMMIT=$(git commit-tree -p $PARENT -m message' $TREE) git push origin $COMMIT:refs/heads/teh-branch write-tree+commit-tree is what git-commit does internally. -- 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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On Thu, Nov 1, 2012 at 1:46 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. Godwin's Law. That went fast, just one day :) -- 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: Why does git-commit --template want the template to be modified ?
On Tue, 30 Oct 2012 11:53:08 +0100, Francis Moreau francis.m...@gmail.com wrote: Hi, I'm using git-commit with the --template option. The template I'm given is self sufficient for my purpose but as stated in the documentation, git-commit wants the template to be edited otherwise it aborts the operation. Is it possible to change this ? It seems you want -F instead of --template. -- 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-pull suggests deprecated git-branch --set-upstream flag
I just ran git pull, and it suggested that I should use `git branch --set-upstream`. Yet when I used it, git-branch told me that the flag is deprecated. Git version 1.8.0. 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: erratic behavior commit --allow-empty
On Wed, 03 Oct 2012 10:24:00 +0200, Angelo Borsotti angelo.borso...@gmail.com wrote: create a new one. To force it to create a brand new one I added --allow-empty to it because the man page stated that it would bypass the check that prevents to make a new one. The I discovered that sometimes --allow-empty does not behave as expected. The documentation only states that it will skip the 'same tree as parent' check, not that it will *always* create a new commit. -- 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 an case-insensitive Mac OS X filesystem
On Tue, Sep 11, 2012 at 9:30 AM, Roger Pau Monné roger@entel.upc.edu wrote: On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné roger@entel.upc.edu wrote: Hello, I'm using git for all my projects, and I usually work under Mac OS X with the default filesystem (that's case-insensitive, but case-preserving). I'm currently working on a project that has several branches, and two of them are called origin/DHCPCD and origin/dhcpcd respectively, that's unfortunate, but I cannot do anything about it. This completely breaks the git repository, because .git/refs/remotes/origin/DHCPD and .git/refs/remotes/origin/dhcpd are actually the same file, so when I try to update my repository performing a git pull I get the following error: error: Ref refs/remotes/origin/dhcpcd is at 6b371783de2def2d6e3ec2680ba731f7086067ee but expected 79f701ce599a27043eed8343f76406014963278a So I was wondering if anyone has stumbled upon this issue, and what's the best approach to fix it. Make a disk image and format it with a case sensitive filesystem (use the Disk Utility to do that). Do your work there. Yes, I could also create a partition, or format my entire disk to case-sensitive (although I heard it might break some OS X applications), I guess adding a workaround for this in git itself is not appealing (like storing the branch file using a slightly different name?) No, I'm not talking about a partition. I'm talking about a Mac OS X disk image (eg. http://en.wikipedia.org/wiki/.dmg). -- 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
Renaming a remote is 'rename', but removing is 'rm'
A fella on IRC was confused by $subject. And it did bother me sometimes as well. If you don't use `git remote` often, it is confusing that the commands are named inconsistently. If I know that there is `git remote rm` then I kindof expect `git remote mv` to exist. Because I am used to rm/mv and git rm/git mv as the standard unix commands for renaming and removing something. On the other hand, if I know that there is `git remote rename`, with the verb fully written out, I expect `git remote delete/remove` to exist (or something similar, with the verb fully written out). Would there be any desire to make the subcommands more consistent in that regard? 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
