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
