Re: Git branch deletion not based on HEAD branch anymore
> There's "branch --merged" already. And in recent versions of git, the > scriptable for-each-ref knows it, too. So you could do something like: > > git for-each-ref --format='delete %(refname)' --merged HEAD refs/heads/ | > grep -v 'any-branches-you-want-saved' | > git update-ref --stdin Yeah I wanted to avoid anything else that git branch -d, as it doesn't delete the currently checked out. I am not really familiar with plumbing commands. > The "--merged" option to git-branch is only used for listing. In theory > we could use it for selection in other operations, like "git branch -d > --merged". But I'm not sure how you'd tell it _not_ to delete the branch > that matches HEAD. Last time I checked git branch doesn't delete the currently checked out branch, does it? Adding the --merged to `git branch -d` would be awesome Javier
Git branch deletion not based on HEAD branch anymore
Hello, I have noticed that in the "latest" versions of git, `git branch -d branch` instead of refusing to delete a branch that hasn't been merged to HEAD, it now throws a warning and deleting the local branch if it's present in a remote. Example: ``` > git branch -d command-runner warning: deleting branch 'command-runner' that has been merged to 'refs/remotes/origin/command-runner', but not yet merged to HEAD. Deleted branch command-runner (was 1716ed5). ``` After diving in git blame for a while I have realized that "lately" refers to a commit done in 2009. Because the change is over 7 years old, I will explain what is my use case. The workflow I follow since I started with git is to start an exact replica of my working environment in a personal fork. Anything deleted locally is deleted remotely and viceversa. This allows me to move between work and home smoothly. I also use the default `git config push.default matching` My typical day starts and ends pulling master from the central repo, and `git branch -d`-ing all the branches I have in local. git would delete the ones that have been merged, and leave alone the ones that have been not been merged. Then I rebase all my branches and push the new master and rebased branches. Because all my local branches track my personal repo, all of them get deleted if I execute my scripts. I understand it's not possible / convenient anymore to go back, but would it be possible to have an option such as `--merged` to support the old usecase? -- Javier Domingo Cansino
Re: [GSoC] A late proposal: a modern send-email
> While Gmail provides SMTP access, it was (last I was told) > incompatible with two-factor auth; so I've encountered users > unable to send patches with their normal 2FA-enabled accounts. > > Maybe git hackers at Google have enough pull to lobby Gmail's > web interface to make it easier to send plain-text patches; > but I would love more to see users running local mail clients > and even running their own SMTP servers. Just in case, I use git send email with my gmail account and I have 2 step auth configured. The only "limitation" however is that you have to create a password for each email client on it's own. If you own a gmail account, go to https://security.google.com/settings/security/apppasswords to create a password for the email client. -- Javier Domingo Cansino -- 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] diff: handle "-" as abbreviation of '@{-1}'
dash is usually used for representing stdin / stdout as a file. I
think this could drive to error... but I would agree with transforming
-h1 to @{-1} or -h2 to @{-2} (-h representing head).
I do agree however that all those signs are thought with american
keyboards in mind. All those punctuation marks are usually hard to
type in other keyboards, and -h1 is way simpler than HEAD~ or @{-1}
This links provides an example of my worry:
http://stackoverflow.com/questions/15270970/is-it-possible-to-git-diff-a-file-against-standard-input
On Sat, Mar 12, 2016 at 2:11 AM, Senorsen <senorsen.zh...@gmail.com> wrote:
>
> Currently it just replace "-" in argv[] into "@{-1}".
>
> For example,
>
> git diff -
>
> equals to
>
> git diff @{-1}
>
> Signed-off-by: Senorsen <senorsen.zh...@gmail.com>
> ---
> Notes:
> Hello everyone, I'm Zhang Sen, a college student from Zhejiang University
> in China, and this is a patch for the microproject of GSoC 2016. I'm
> looking forward to contributing to Git and participating in GSoC 2016.
>
> I have learnt some rules and guides from the documents, and carefully
> wrote this small patch, according to other code from git.
>
> Thanks a lot!
>
> builtin/diff.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/builtin/diff.c b/builtin/diff.c
> index 52c98a9..c110141 100644
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -389,6 +389,11 @@ int cmd_diff(int argc, const char **argv, const char
> *prefix)
> }
> }
>
> + for (i = 0; i < argc; i++) {
> + if (!strcmp(argv[i], "-"))
> + argv[i] = "@{-1}";
> + }
> +
> for (i = 0; i < rev.pending.nr; i++) {
> struct object_array_entry *entry = [i];
> struct object *obj = entry->item;
> --
> 2.7.0
>
> --
> 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
--
Javier Domingo Cansino
--
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: Doing a git add '' will add more files then expected
IMO, if you put an empty string you would be implying the same as with a dot (git add . ). The important thing is that git add without a pathspec returns an error, as it has always done, mainly because it people tend to work without gitignoring all the files they should, and allowing such behaviour would make things harder. -- Javier Domingo Cansino -- 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: Fwd: Add git ignore as builtin
I would love to have such tool included in the toolchain, but being able to use it to edit all the ignore chain, defaulting to .gitignore. Explain the reason in my case. Usually, when ignoring stuff, you will probable ignore already your IDE/Editor files using a global gitignore. And most of the times in a per-project basis, you will be ignoring their output files. I only use .git/info/exclude when I have something really special that I don't want to share publicly, such as a data/ folder to run the project or so. That way, most of the times I will be modifying .gitignore, sometimes my global gitignore and very occasionally, .git/info/exclude. That's my case, and that I know of, people have that usage order, .gitignore global gitignore local gitignore. For sake of uniformity, I would use the same context specifiers as in git-config. Defaulting to --repo for .gitignore, using --local for the .git/info/exclue, using --global for the global gitignore, and --system for the system one. Also, about adding and excluding, I would recommend using verbs instead of arguments, which would be in consonance with git remote. git ignore exclude git ignore include You could also make it smart by allowing to use it as the Cisco managing commands, or the ip tool (ip a == ip address, ip a a == ip addr add, etc.), resulting in the following: git ignore e git ignore i -- Javier Domingo Cansino -- 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: Branching workflow
Hello!, I have been using this workflow you suggested, and I happen to find it really good fitting in many projects I am. I would like to seek for a little more advice. I keep rebasing all my work each time master branch is updated, and I would like to know if this is usually done or not. The workflow is not using emails, but each developer has his clone where he works, and occasionally sends work to the gerrit tool we use, upgrading the patch with each master update. I know this is a crazy workflow, and I would like to know when you usually consider to update the sent patch with a rebase. Cheers, -- Javier Domingo Cansino -- 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: Idea, Transparent commits, easier code style commits
They just have to look into the commit message and look for #codestylefix or whatever other string. In many projects I have seen, they have a format for commits, such as docs: Add support for XXX, formatting: Space before parethesis and after comas, tests: and so on. Maybe, being able to specify a RegExp would be the way to go, so that git blame did actually ignore those commits. -- 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: Can we stage all files using git add command, except some specific files ?
If you don't want an specific file, but you neither the .gitignore, just use .git/info/exclude file for project specific or $HOME/.config/git/ignore for user level. Anyway, this is all in man gitignore [1] Git ignore man page: http://git-scm.com/docs/gitignore Javier Domingo Cansino 2014-05-26 21:27 GMT+02:00 Arup Rakshit arupraks...@rocketmail.com: On Monday, May 26, 2014 10:23:22 PM you wrote: On di, 2014-05-27 at 00:33 +0630, Arup Rakshit wrote: Now, you can see, I have staged all the files first using *git add -A*, then _unstaging_ those I don't want to _stage_ right now. Now can this be done, in the *staging* time ? I mean any way to tell `git add` command, that add all the files from the current directory, except some specific files. No, there is no such option to do that, but you could use git add --interactive and use its interface to quickly pick the files you want to add. Hi, I tried it also.. But just didn't get it, how to use,, lots of options 1,2,3 etc .. :) -- === Regards, Arup Rakshit -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe's === = The publish tracking branch = I still have problems getting upstream branches correctly configured as to have this introduced, anyway, I suppose it's optional, so nothing to add on that. By the way, remote branch managing has improved a lot, one of the best things I see for branching and remotes is the git remote show command, but I think further work should be done. Help messages FTW! = Reject non-fast-forward pulls by default = Not having this introduced yet allows newbie people to use git with just 4 commands, without bothering around with fetch and merge and so. = Use stage instead of index = Totally agree with this. = Default aliases = I hate aliases, make scripts more difficult to read and understand. I would instead try to improve knowledge on this feature. I have to agree with David Lang's first message, and The cherry-pick = pick thing would be the only thing I would see with good eyes, just because it's too long and has a dash. Juno's == The idea about ~/.gitconfig seems incredible simple and effective to me. I would however try to keep it simple, and minimize the form. Mine I have taught (or tried to) a lot of people Git. And this is some of the stuff I have seen they have difficulties with: - Remembering the commands, for example, remembering add, commit push and pull, which I think we can all agree is the most core and simple combination of Git commands. - What command comes for what they need. If I want to share everything, what should I do? - Most of them, have real difficulties on remembering the flows. There are too many commands for the start. I wouldn't nevertheless suppress any of them, I would rather do a tuto on-the-go. Here are some ideas I have thought of: == Command Output== At the moment, there are several commands that don't output any help text, and many others, that although they have become more verbose with the years, they aren't too verbose yet. One of the things I most recommend to anyone is to run git status just before any command (push, commit, add, etc.) to get sure they are doing what they thing they will. For example, running git add won't tell you what you just added, nor what you could do now. I would put some output there, maybe the git status output or something similar that helps the user to know what just happened. Git status doesn't say much about remotes, and suggesting pushing if a remote is outdated, would be fantastic. Checkout command has decreased verbosity from a previous version, where it stated which branch it came from and to which branch it was switching to. As an extreme thing, I would consider adding a configuration parameter default, core.helptext=True that could switch off all this stuff. ==Running git== This is a very basic idea, and I suppose it isn't too helpful or realistic, but might give someone an idea. I would first make that running git, just git, tell the user the possibilities he has. I don't know of any power user that uses git to remember the commands. At the moment, git[1] just tells many of the commands available, without any classification, maybe classifying them as commiting branching and remote could help a little. Regards, Javier Domingo Cansino [1] git output: javier@frodo:~$ git usage: git [--version] [--help] [-C path] [-c name=value] [--exec-path[=path]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=path] [--work-tree=path] [--namespace=name] command [args] The most commonly used git commands are: addAdd file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty Git repository or reinitialize an existing one logShow commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and integrate with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tagCreate, list, delete or verify a tag object signed with GPG 'git help -a' and 'git help -g' lists available subcommands and some concept guides. See 'git help
Re: Our official home page and logo for the Git project
I think it is a suitable logo. It might not be the one I would think of, but I see with good eyes using it as one of the project logos. Javier Domingo Cansino -- 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: Our official home page and logo for the Git project
I have never thought on that logo as the Git logo (the red one), and thought it was [1]. Mainly because the logo itself has git inside. I have to agree with David Kastrup on that I see no connection to git only by the image (red one). Maybe is because I am accustomed to the older one[1] I started with. BTW, I don't know if the old logo I am accustomed to has ever been used by the project officially, but I always thought it was that one. Javier Domingo Cansino [1] Git logo: http://git-osx-installer.googlecode.com/files/GitLogo.jpg -- 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: [ANNOUNCE] Git v1.9-rc0
Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Cheers Javier Domingo Cansino [1] Google Code download service change announcement: http://google-opensource.blogspot.se/2013/05/a-change-to-google-code-download-service.html [2] Google Code download section FAQ: https://code.google.com/p/support/wiki/DownloadsFAQ -- 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
Branching workflow
Hi, I have been using a very basic workflow for branching, features each in a branch. My branches would be: - develop = Main upstream branch - feature/* fix/* = Feature and fix branches - master = Integration of the whole feature and fix branches So I have now came up with a very difficult task. I just discovered that one of those branches, lest call it feature/bad, is evil and is making the integration branch (master) fail horribly. In my workflow, I tend to merge develop (official updates) into my feature branches, and them into master. So now I have the big problem on how to undo all changes from feature/fix. I have been told that one alternative workflow would be to revert the last merge and remerge it into master, so that I have always just one commit to revert if necessary (instead of the monstrous quantity I have now to). The workflow proposal should be in order of importance: - Let me stay up-to-date with develop branch - Easy to revert in master - Have a clean history - Easy to follow I think I should be capable of doing some sort of merge/rebase branching workflow to avoid having to do that. I have thought about rebasing always the feature branches, and rebasing master into all of them, but it seems pretty strange to me. If anyone can give any advice, I would fully appreciate! Javier Domingo Cansino -- 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: Branching workflow
Hi John!, Thanks a lot for your tip, but I have the problem that I would need to have a linear history in master (forgot to mention it explicitly) ;( I build on master branch, and getting to a previous version is hereby needed. I had thought about the revert workflow, but using --no-commit. I would then have a way to mark stuff as re-mergeable. I am pretty lost with this. Is like a non-ending hell, because I have to provide linear history to master and develop, and allowing master to be revertable. Isn't there something like git revert branch-name so that all commits that have been merged from that branch, and don't belong to any other, can be reverted? With this history: A-B-C := develop B-D-Z-Y := feature/bad B-D-G-H := feature/good A-B-C-z-g-y-h := master (caps original commits, regular merged commits) so that: git checkout master git revert feature/bad would revert z and h in master history, in one single commit, and making available merging feature/bad when it's ready, with all conflicting if needed. Ideas welcome =) Javier Domingo Cansino 2013/12/3 John Keeping j...@keeping.me.uk: On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote: I have been using a very basic workflow for branching, features each in a branch. My branches would be: - develop = Main upstream branch - feature/* fix/* = Feature and fix branches - master = Integration of the whole feature and fix branches So I have now came up with a very difficult task. I just discovered that one of those branches, lest call it feature/bad, is evil and is making the integration branch (master) fail horribly. In my workflow, I tend to merge develop (official updates) into my feature branches, and them into master. So now I have the big problem on how to undo all changes from feature/fix. I have been told that one alternative workflow would be to revert the last merge and remerge it into master, so that I have always just one commit to revert if necessary (instead of the monstrous quantity I have now to). The workflow proposal should be in order of importance: - Let me stay up-to-date with develop branch - Easy to revert in master - Have a clean history - Easy to follow I think I should be capable of doing some sort of merge/rebase branching workflow to avoid having to do that. I have thought about rebasing always the feature branches, and rebasing master into all of them, but it seems pretty strange to me. If anyone can give any advice, I would fully appreciate! It sounds like you want a throwaway integration branch. This is similar to the workflow Junio uses with git.git's pu branch, which involves rebuilding a branch by: * resetting it to some base (develop in your case) * merging in the required feature branches This may not quite be what you want because it does mean that you cannot build on the integration branch - it is intended to be rewritten often, but it does provide a good platform for testing features and then merging them to a stable branch once they have proved to be good. The advantage is that you know that the integration merges are temporary and you can test on top of that without having set the result in stone. shameless plugIf you are interested in such a workflow then you may want to try my git-integration program [1] to manage integration branches. There is also a reimplementation in Ruby with a slightly different feature set [2] [1] http://johnkeeping.github.io/git-integration [2] http://github.com/felipec/git-reintegrate -- 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: Branching workflow
I will start to rebase all feature branches because I have no real dependency on those, but master needs to have a linear history, as I build from it regularly, and I need to assure that people can get a previous version of master. The problem with that is that I wouldn't be able to have a linear history on master. I had also thought about doing a snapshot branch of the integration branch, so that I could maintain history of integration, and just update it with integration snapshots, but I am trying to get another more git-ish way to achieve all these requirements of all branches (they are really driving me crazy). Thanks a lot for the idea. I will mantain clean feature branches from now on, Javier Domingo Cansino -- 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
Splitting files merge with branches
Hi, I have been using git for now 4 years, and one feature I miss a lot, that would increase the usability of git in many cases, would be having it detect inter-file movements, so that if I, in a single commit just part one file into many, git can track that change. I suppose this is quite difficult, as would mean having extra features in diffs, and I don't know how could it be implemented, but that would ease even more having integration branches, and merging one with eachother. I wouldn't either know how to split it, in the means that if 5 lines are in the middle of a split, where would those lines go? But as you have resolved quite variety of problems, you might now a way. Just wanted to collaborate with my idea =) Cheers, Javier Domingo Cansino -- 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] Disabling status hints in COMMIT_EDITMSG
IMHO, It is alright as it is. I have been using git for 4~ years now, and I still find very useful those lines. They are like a git status while committing, and it's the key to avoid accidental commits of objects or forgetting files in a commit. Between that and that the commit message can't be empty, I can abort a commit and correct the staging area. Cheers, Javier Domingo -- 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] Disabling status hints in COMMIT_EDITMSG
That extra info doesn't occupy too much, and helps distinguish between sections. They do also remember you the commands to use (thought after some time using git, you may not need it). Cheers, Javier -- 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: Making a (quick) commit to another branch
2013/4/27 Johannes Schneider maili...@cedarsoft.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, I love git. And I use it every day. But there is one minor thing, that bugs me a little bit: I am implementing something on a feature branch. Now I detect a minor typo/bug/whatever that just needs a one line commit. But of course I don't want to add that commit to my feature branch. Instead I'd like to commit that fix directly to another branch (e.g. master). Unfortunately that take a lot of steps to make this happen: - - comitting - - stashing other changes - - changing branch - - cherry-picking commit - - switching branches back - - reverting latest commit - - unstashing changes I'd love to solve this by having an option for git commit that gives me the possibility to commit to another branch: git commit thefixedfile.txt -m fixed a typo -b master Any ideas/hints? I would first recommend you, instead of cherry-picking the commit, you did this: -- stash -- go to the master branch -- fix the line -- commit the fix -- got to the feature branch -- unstash As when you merge with master, git will carry on with the changes. I don't see the need to cherry pick that commit. Javier Domingo -- 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: Fwd: Strange remote interaction
In a usual set-up, an access to git@server:javier/pfc will first locate the home directory for the user git (the token before @), and then its subdirectory javier/pfc, e.g. /home/git/javier/pfc, while an access to server:javier/pfc will first locate the home directory of whatever username the ssh connection uses by default (typically the local user but ~/.ssh/config may have User directive for the server) and then its subdirectory javier/pfc, e.g. /home/javier/javier/pfc. These two may be different locations. Do these two commands show the same output? $ git ls-remote git@server:javier/pfc refs/heads/master $ git ls-remote server:javier/pfc refs/heads/master If the above conjecture is correct, I suspect they don't. I have a gitolite setup there, so it is imposible the give the same output. Anyways, as I don't have a user in the server machine, the second fails. $ git ls-remote git@server:javier/pfc 22692a2d69d3138b7ccebd64e72c66ea8bf69e9f HEAD 22692a2d69d3138b7ccebd64e72c66ea8bf69e9f refs/heads/master It is the first time I encounter such a problem. -- 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
Fwd: Strange remote interaction
Hi, I have just had the attached bash session, and I have no idea on what is going on. Any help appreciated, Javier Domingo bug Description: Binary data
Re: Fwd: possible Improving diff algoritm
I must say it is _quite_ helpfull having the diffs well done (natural diffs as here named), just because when you want to review a patch on the fly, this sort of things are annoying. I just wanted to say my opinion. No idea on how to fix that, nor why does it happen. Javier Domingo 2012/12/12 Andrew Ardill andrew.ard...@gmail.com: On 13 December 2012 08:53, Junio C Hamano gits...@pobox.com wrote: The output being a correct patch is not the only thing we need to consider, though, as I mentioned in another response to Kevin regarding the consequences. The main benefit of picking a more 'natural' diff is a usability one. I know that when a chunk begins and ends one line after the logical break point (typically with braces in my experience) mentally parsing the diff becomes significantly harder. If there was a way to teach git where it should try and break out a chunk (potentially per filetype?) this is a good thing for readability, and I think would outweigh any temporary pain with regards to cached rerere and diff data. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Local clones aka forks disk size optimization
Hi Andrew, The problem about that, is that if I want to delete the first repo, I will loose objects... Or does that repack also hard-link the objects in other repos? I don't want to accidentally loose data, so it would be nice that althought avoided to repack things, it would also hardlink them. Javier Domingo 2012/11/15 Andrew Ardill andrew.ard...@gmail.com: On 15 November 2012 10:42, Javier Domingo javier...@gmail.com wrote: Hi, I have come up with this while doing some local forks for work. Currently, when you clone a repo using a path (not file:/// protocol) you get all the common objects linked. But as you work, each one will continue growing on its way, although they may have common objects. Is there any way to avoid this? I mean, can something be done in git, that it checks for (when pulling) the same objects in the other forks? Have you seen alternates? From [1]: How to share objects between existing repositories? --- Do echo /source/git/project/.git/objects/ .git/objects/info/alternates and then follow it up with git repack -a -d -l where the '-l' means that it will only put local objects in the pack-file (strictly speaking, it will put any loose objects from the alternate tree too, so you'll have a fully packed archive, but it won't duplicate objects that are already packed in the alternate tree). [1] https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F Regards, Andrew Ardill -- 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: Local clones aka forks disk size optimization
Hi Andrew, Doing this would require I got tracked which one comes from which. So it would imply some logic (and db) over it. With the hardlinking way, it wouldn't require anything. The idea is that you don't have to do anything else in the server. I understand that it would be imposible to do it for windows users (but using cygwin), but for *nix ones yes... Javier Domingo 2012/11/15 Andrew Ardill andrew.ard...@gmail.com: On 15 November 2012 11:40, Javier Domingo javier...@gmail.com wrote: Hi Andrew, The problem about that, is that if I want to delete the first repo, I will loose objects... Or does that repack also hard-link the objects in other repos? I don't want to accidentally loose data, so it would be nice that althought avoided to repack things, it would also hardlink them. Hi Javier, check out the section below the one I linked earlier: How to stop sharing objects between repositories? To copy the shared objects into the local repository, repack without the -l flag git repack -a Then remove the pointer to the alternate object store rm .git/objects/info/alternates (If the repository is edited between the two steps, it could become corrupted when the alternates file is removed. If you're unsure, you can use git fsck to check for corruption. If things go wrong, you can always recover by replacing the alternates file and starting over). Regards, Andrew Ardill -- 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
