Re: feature request: user email config per domain

Hi Tushar, On 22/02/2017 14:12, Tushar Kapila wrote: > So when remote URL has github.com push as tgkp...@search.com but for > testing.abc.doman:8080 use tgkp...@test.xyz.com ? I`m not sure if this is sensible, as authorship information is baked into the commit at the time of

Re: feature request: user email config per domain

On Wed, Feb 22, 2017 at 06:42:02PM +0530, Tushar Kapila wrote: > Feature request : can we have a config for email per repo domain ? > Something like: > > git config --global domain.user.email tgkp...@test.xyz.com > testing.abc.doman:8080 > > git config --global d

Re: feature request: user email config per domain

On 23 February 2017 at 00:12, Tushar Kapila wrote: > I can set my email via: > git config --global user.email tgkp...@xyz.dom > > this is dangerous when I use this my office or in a multi repository > provider environment where my email is different for a few (like >

Re: feature request: user email config per domain

Hey Tushar, When you run `git config --global user.email a...@xyz.com` it writes out this setting in ~/.gitconfig which is then considered to be "global" ie. this same email will be used for every repo, but ... You can always override this. Let's say there is a repo named "foo" in which you want

feature request: user email config per domain

(only master branch), and we have 57 emails out of 346 which are not the company email. Also in there are cases when name is the same but some commits are by email 1 and others by email 2, because of this global config. As some of us work on open source and company repos on the same computer. Feature

Re: Feature request: flagging “volatile” branches for integration/development

"Herbert, Marc" writes: >> The hard part may be policy (e.g. what if the user does not want a branch >> to be treated volatile by various commands even if it receives such >> flag from a git server). > > There would be instant, human-readable value in such a new

Re: Feature request: flagging “volatile” branches for integration/development

[apologies for the accidental "smart" quotes and the resulting UTF8 encoding of the subject] On 04/02/2017 06:01, Duy Nguyen wrote: > > But that would be local information only. We don't have ways to > transfer branch metadata (and we definitely don't want to just share > .git/config file with

Re: feature request: add -q to "git branch"

I think I got my git versions (old and new) mixed up. Sorry for the noise. On Sat, Feb 4, 2017 at 1:17 PM, Pranit Bauva wrote: > Hey Kevin, > > Sorry for the previous message. > > On Sun, Feb 5, 2017 at 2:47 AM, Pranit Bauva wrote: >> Hey Kevin,

Re: feature request: add -q to "git branch"

Hey Kevin, Sorry for the previous message. On Sun, Feb 5, 2017 at 2:47 AM, Pranit Bauva wrote: > Hey Kevin, > > On Fri, Feb 3, 2017 at 11:59 PM, Kevin Layer wrote: >> It should be possible to quietly create a branch. I think `git branch` is already

Re: feature request: add -q to "git branch"

Hey Kevin, On Fri, Feb 3, 2017 at 11:59 PM, Kevin Layer wrote: > It should be possible to quietly create a branch. > > Thanks. > > Kevin

Re: Feature request: flagging “volatile” branches for integration/development

On Wed, Feb 1, 2017 at 12:12 AM, Herbert, Marc wrote: > (Thanks to Josh Triplett[*] for contributing to this message) > > Hi, > > We often work with development/integration branches that regularly > rebase, in addition to stable branches that do not. Git is used to share >

feature request: add -q to "git branch"

It should be possible to quietly create a branch. Thanks. Kevin

Feature request: flagging “volatile” branches for integration/development

(Thanks to Josh Triplett[*] for contributing to this message) Hi, We often work with development/integration branches that regularly rebase, in addition to stable branches that do not. Git is used to share two different types of branches: 1. Pull requests and merged code with final SHA1s 2.

Re: feature request: allow to stash changed files

On 01/15, KES wrote: > http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833 > > Sometimes poople are forced to save stash for changed files. But there is no > such option ( You may just be lucky. I've been

feature request: allow to stash changed files

http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833 Sometimes poople are forced to save stash for changed files. But there is no such option (

Re: Feature request: git rebase --no-edit --continue

Uff, I forgot about the CC of my last reply. Why not git commit -C HEAD && git rebase --continue ? Ciao, Johannes Thanks this is a cleaner solution. I guess because I was too fixed upon knowing of the existence of the no-edit option from other git commands that I forget about this,

Re: Feature request: git rebase --no-edit --continue

Hi Daniel, On Thu, 22 Dec 2016, Daniel Chumak wrote: > Is there a reason why there is no '--no-edit' option for git rebase? I would > like to use this option after editing a commit and continuing the current > interactive rebase without having to change the commit message. Why not git

Re: Feature request: git rebase --no-edit --continue

On Thu, Dec 22, 2016 at 2:35 PM, Daniel Chumak wrote: > Is there a reason why there is no '--no-edit' option for git rebase? Nobody added it so far. > I would > like to use this option after editing a commit and continuing the current > interactive rebase without

Feature request: git rebase --no-edit --continue

Is there a reason why there is no '--no-edit' option for git rebase? I would like to use this option after editing a commit and continuing the current interactive rebase without having to change the commit message.

Re: Feature request: read git config from parent directory

On Friday, 9 December 2016 19:38:05 CET Duy Nguyen wrote: > >> Sounds like the same problem I have (and the reason I came up with > >> conditional include [1]). Would that work for you (check out the > >> example part in that patch)? > > > > If I understand correcly, I would need to set up config

Re: Feature request: read git config from parent directory

On Fri, Dec 9, 2016 at 2:49 AM, Dominique Dumont wrote: > Hello > > I use the same machine for work and open-source contribution. In both cases, I > deal with a lot of repositories. Depending on whether I commit for work or > open-source activities, I must use a different mail

Feature request: read git config from parent directory

Hello I use the same machine for work and open-source contribution. In both cases, I deal with a lot of repositories. Depending on whether I commit for work or open-source activities, I must use a different mail address. I used to setup work address for each work repo in git local config, but

Re: Re: Feature request: Set git svn options in .git/config file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Am 05.12.2016 um 23:54 schrieb Eric Wong: > So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor > config keys work and can be documented? yes, I can confirm, that adding this configuration keys works with git 2.1.4 work. I have

Re: Feature request: Set git svn options in .git/config file

Juergen Kosel wrote: > Therefore I believe, that it would be the best solution to store the > settings of --add-author-from, --use-log-author and maybe > --authors-prog in the .git/config file. Actually, "svn.authorsProg" is already documented as a config option for

Feature request: Set git svn options in .git/config file

Hello, while working with a git-svn repository, I like to use the command line options --use-log-author and --add-author-from for all calls of git svn fetch, git svn rebase, git svn dcommit, ... Doing so consequently, the commit-ids of each git repository, which has been cloned from the same

Re: [feature request] Make "commit --only" work with new files

Luis Ressel writes: > currently "git commit --only " only works if is already > checked into the repo, but not with newly created and still untracked > files (builtin/commit.c:list_path() throws the error "error: pathspec > '' did not match any file(s) known to git.") The fact

Re: [feature request] Make "commit --only" work with new files

Hi Luis, On Fri, 25 Nov 2016, Luis Ressel wrote: > currently "git commit --only " only works if is already > checked into the repo, but not with newly created and still untracked > files (builtin/commit.c:list_path() throws the error "error: pathspec > '' did not match any file(s) known to

[feature request] Make "commit --only" work with new files

Hello, currently "git commit --only " only works if is already checked into the repo, but not with newly created and still untracked files (builtin/commit.c:list_path() throws the error "error: pathspec '' did not match any file(s) known to git.") I don't think this limitation is intented. I've

Re: Feature request: Improve diff algorithm

On Mon, Nov 21, 2016 at 10:17 AM, Stefan Beller wrote: > On Mon, Nov 21, 2016 at 8:56 AM, Jacob Keller wrote: >> On Mon, Nov 21, 2016 at 12:11 AM, KES wrote: >>> Hi. >>> >> >> Hi, >> >>> I have some question about how diff works

Re: Feature request: Improve diff algorithm

On Mon, Nov 21, 2016 at 8:56 AM, Jacob Keller wrote: > On Mon, Nov 21, 2016 at 12:11 AM, KES wrote: >> Hi. >> > > Hi, > >> I have some question about how diff works then give proposal: >> >> it will be very useful for each "symbol" store additional meta

Re: Feature request: Improve diff algorithm

On Mon, Nov 21, 2016 at 12:11 AM, KES wrote: > Hi. > Hi, > I have some question about how diff works then give proposal: > > it will be very useful for each "symbol" store additional meta info as source > line length. So in this case when git counter two equal sequence of

Feature request: Improve diff algorithm

Hi. I have some question about how diff works then give proposal: it will be very useful for each "symbol" store additional meta info as source line length. So in this case when git counter two equal sequence of commands it will do further comparison: Adds 23 chars deletes none VS adds 75

Re: Feature request - show result of URL rewrites

Dennis Kaarsemaker writes: >> Git lets you rewrite URLs using "url..insteadOf" >> ... >> Can you add a git-config option to show the result of this rewriting >> whenever this occurs, as debugging more complicated rules can be >> difficult/wasn't obvious without

Re: Feature request - show result of URL rewrites

On Sat, 2016-11-12 at 18:49 +0100, Git User wrote: > Hello > > Hopefully this is the right place to submit feature requests - let me > know if there's somewhere else I should use! > > Git lets you rewrite URLs using "url..insteadOf" > > https://stackoverflow.com/a/11383587 >

Feature request - show result of URL rewrites

Hello Hopefully this is the right place to submit feature requests - let me know if there's somewhere else I should use! Git lets you rewrite URLs using "url..insteadOf" https://stackoverflow.com/a/11383587 https://git-scm.com/docs/git-config Can you add a git-config option to show the result

Re: feature request

From: "David Lang" On Thu, 27 Oct 2016, John Rood wrote: Thanks, I think changing the default for windows is a good idea. notepad doesn't work well with unix line endings, wordpad handles the files much more cleanly. David Lang Notepad++ does work well, but isn't a

Re: feature request

Hi, On Thu, 27 Oct 2016, David Lang wrote: > On Thu, 27 Oct 2016, John Rood wrote: > > > Thanks, I think changing the default for windows is a good idea. > > notepad doesn't work well with unix line endings, wordpad handles the files > much more cleanly. That is why we have a `notepad` helper

Re: feature request

On Thu, 27 Oct 2016, John Rood wrote: Thanks, I think changing the default for windows is a good idea. notepad doesn't work well with unix line endings, wordpad handles the files much more cleanly. David Lang

Re: feature request

Thanks. I wasn't aware of --no-edit, but that is indeed exactly what I was looking for. I think your point about encouraging users to make good use of commit messages is good. My concern though is that vim isn't encouraging users to leave good messages as much as it is scaring them away from

Re: feature request

John Rood writes: [administrivia: do not top post] > What I'm really seeking is not a make-shift solution for myself, but > an intuitive solution for the novice user-base at large. Well, there are -m and --no-edit. Recording commits with useless single liner is a bad

Re: feature request

What I'm really seeking is not a make-shift solution for myself, but an intuitive solution for the novice user-base at large. On Thu, Oct 27, 2016 at 5:27 PM, Junio C Hamano wrote: > John Rood writes: > >> I suppose I can do git config --global

Re: feature request

John Rood writes: > On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller wrote: >> On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >>> Users should be able to configure Git to not send them into a Vim editor. >>> >>> When users

Re: feature request

Thanks, I think changing the default for windows is a good idea. The -m indeed accomplishes one-line messages when you are voluntarily doing a commit. However, the scenario I mentioned is "When users pull commits, and a new commit needs to be created for the merge" In this situation, the user

Re: feature request

On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: > Users should be able to configure Git to not send them into a Vim editor. > > When users pull commits, and a new commit needs to be created for a > merge, Git's current way of determining a commit message is to send > the

Re: feature request

John Rood writes: > I suppose I can do git config --global core.editor notepad > However, this really only addresses my second concern. > > My first concern is that using a text editor at all seems like > overkill in many scenarios. Nobody stops you from writing a "type

Re: feature request

I suppose I can do git config --global core.editor notepad However, this really only addresses my second concern. My first concern is that using a text editor at all seems like overkill in many scenarios. For that reason, I still think the other two options I mentioned would be beneficial. On

Re: feature request

Unfortunately, in my case I'm on windows (my company's choice, not mine). On Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller wrote: > On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >> Users should be able to configure Git to not send them into a Vim

Re: feature request

On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: > Users should be able to configure Git to not send them into a Vim editor. See https://git-scm.com/docs/git-var GIT_EDITOR Text editor for use by Git commands. The value is meant to be interpreted by the shell when it

feature request

Users should be able to configure Git to not send them into a Vim editor. When users pull commits, and a new commit needs to be created for a merge, Git's current way of determining a commit message is to send the user into a Vim window so that they can write a message. There are 2 reasons why

Re: [PATCH 1/2] Feature Request: user defined suffix for temp files created by git-mergetool

On Thu, Oct 06, 2016 at 08:43:02AM -0400, Josef Ridky wrote: > This is the first of two variant for request to add option to change > suffix of name of temporary files generated by git mergetool. This > change is requested for cases, when is git mergetool used for local > comparision between two

Re: [PATCH v2 2/2] Feature Request: user defined suffix for temp files created by git-mergetool

On Wed, Oct 12, 2016 at 10:59:46AM -0700, Junio C Hamano wrote: > Josef Ridky writes: > > > This is update of the second variant for request to add option to change > > suffix of name of temporary files generated by git mergetool. This > > change is requested for cases, when

Re: [PATCH v2 2/2] Feature Request: user defined suffix for temp files created by git-mergetool

Josef Ridky writes: > This is update of the second variant for request to add option to change > suffix of name of temporary files generated by git mergetool. This > change is requested for cases, when is git mergetool used for local > comparison between two version of same

Re: [PATCH v2 2/2] Feature Request: user defined suffix for temp files created by git-mergetool

This is update of the second variant for request to add option to change suffix of name of temporary files generated by git mergetool. This change is requested for cases, when is git mergetool used for local comparison between two version of same package during package rebase. Signed-off-by:

Re: Feature request: use relative path in worktree config files

On Tue, Oct 11, 2016 at 1:36 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >>> I think there are some pros and some cons for relative path and absolute >>> path. >>> Maybe append a "--relative" option with `git worktree add` ? >>> >>> I've converted all

Re: Feature request: use relative path in worktree config files

Duy Nguyen writes: >> I think there are some pros and some cons for relative path and absolute >> path. >> Maybe append a "--relative" option with `git worktree add` ? >> >> I've converted all path to relative and all work with success. >> >> What do you think to append this

Re: Feature request: use relative path in worktree config files

2016-10-09 13:37 GMT+02:00 Duy Nguyen : > On Sun, Oct 9, 2016 at 6:22 PM, Stéphane Klein > wrote: >> 2016-10-09 13:11 GMT+02:00 Duy Nguyen : Why: 1. I configure worktree on my host 2. next I use this git

Re: Feature request: use relative path in worktree config files

On Sun, Oct 9, 2016 at 6:22 PM, Stéphane Klein wrote: > 2016-10-09 13:11 GMT+02:00 Duy Nguyen : > >>> * [worktree_foobar]/.git >> This is made absolute on purpose. So that if you move worktree_foobar >> away manually, it can still point back to >>

Re: Feature request: use relative path in worktree config files

2016-10-09 13:11 GMT+02:00 Duy Nguyen : >> * [worktree_foobar]/.git > This is made absolute on purpose. So that if you move worktree_foobar > away manually, it can still point back to > "[main_worktree]/.git/worktrees/[woktree_foobar]". Same problem if you move origin git

Re: Feature request: use relative path in worktree config files

On Sat, Oct 8, 2016 at 4:35 PM, Stéphane Klein wrote: > Hi, > > "git worktree add" write absolute path in ".git/gitdir" > > The code source is here > https://git.kernel.org/cgit/git/git.git/tree/builtin/worktree.c?h=v2.10.1#n256 > > Is it possible to use relative path

Re: Feature request: use relative path in worktree config files

I've write a small tool in Golang to fix this issue: https://github.com/harobed/fix-git-worktree 2016-10-08 11:35 GMT+02:00 Stéphane Klein : > Hi, > > "git worktree add" write absolute path in ".git/gitdir" > > The code source is here >

Feature request: use relative path in worktree config files

Hi, "git worktree add" write absolute path in ".git/gitdir" The code source is here https://git.kernel.org/cgit/git/git.git/tree/builtin/worktree.c?h=v2.10.1#n256 Is it possible to use relative path in this config files: * [main_worktree]/.git/worktrees/[worktree_foobar]/gitdir *

Re: [PATCH 2/2] Feature Request: user defined suffix for temp files created by git-mergetool

Josef Ridky writes: > + --local=*) > + temp_name=${1#--local=} > + if [ "$temp_name" != "" ] && [ "$temp_name" != "$REMOTE_NAME" ] > && [ "$temp_name" != "$BASE_NAME" ] && [ "$temp_name" != "$BACKUP_NAME" ] > + then > +

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Josef Ridky writes: > I agree, that this patch is written as general as possible and can > possibly bring more confusion than benefits. I am not sure about that. Other people would have similar but different workflow needs where they compare local new one with local old one

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Johannes Sixt writes: > Therefore, I think that your patch as written does not help to reduce > the confusion. It may be a building block for further improvement, but > if you stop here, it is pointless. Yup, you're right.

[PATCH 1/2] Feature Request: user defined suffix for temp files created by git-mergetool

This is the first of two variant for request to add option to change suffix of name of temporary files generated by git mergetool. This change is requested for cases, when is git mergetool used for local comparision between two version of same package during package rebase. Signed-off-by: Josef

[PATCH 2/2] Feature Request: user defined suffix for temp files created by git-mergetool

This is the second of two variant for request to add option to change suffix of name of temporary files generated by git mergetool. This change is requested for cases, when is git mergetool used for local comparison between two version of same package during package rebase. Signed-off-by: Josef

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi Johannes, thank you very much for this reply. | Sent: Wednesday, October 5, 2016 11:04:17 PM | | Am 05.10.2016 um 09:47 schrieb Josef Ridky: | > Add support for user defined suffix part of name of temporary files | > created by git mergetool | | Do I understand correctly that your users

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi Junio, thank you very much for the tips. I'll make new patch with a simpler code. Josef | Sent: Wednesday, October 5, 2016 6:05:59 PM | Josef Ridky writes: | | > Hi, | > | > I have just realize, that my attachment has been cut off from my previous | > message. | > Below

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Am 05.10.2016 um 09:47 schrieb Josef Ridky: Add support for user defined suffix part of name of temporary files created by git mergetool Do I understand correctly that your users have problems to identify which of the "_BASE_", "_LOCAL_", "_REMOTE_" and "_BACKUP_" files they must edit? I

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Josef Ridky writes: > Hi, > > I have just realize, that my attachment has been cut off from my previous > message. > Below you can find patch with requested change. > > Add support for user defined suffix part of name of temporary files > created by git mergetool > --- The

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi David, thank you very much for your reply. Today I realized, that my attachment has been cut off, so I sent it in the morning [1]. I believe, that most of answer can be find in my previous email from this morning. Only change, that should be done by this request is add possibility to edit

Re: Feature Request: user defined suffix for temp files created by git-mergetool

On Tue, Oct 04, 2016 at 01:18:47AM -0400, Josef Ridky wrote: > Hi Anatoly, > > > | Sent: Monday, October 3, 2016 5:18:44 PM > | > | Hi Josef, > | > | > | On Mon, Oct 3, 2016 at 8:36 AM, Josef Ridky wrote: > | > In several projects, we are using git mergetool for comparing

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi, I have just realize, that my attachment has been cut off from my previous message. Below you can find patch with requested change. Add support for user defined suffix part of name of temporary files created by git mergetool --- Documentation/git-mergetool.txt | 26 -

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi Anatoly, | Sent: Monday, October 3, 2016 5:18:44 PM | | Hi Josef, | | | On Mon, Oct 3, 2016 at 8:36 AM, Josef Ridky wrote: | > In several projects, we are using git mergetool for comparing files from | > different folders. | > Unfortunately, when we have opened three

Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi Josef, On Mon, Oct 3, 2016 at 8:36 AM, Josef Ridky wrote: > In several projects, we are using git mergetool for comparing files from > different folders. > Unfortunately, when we have opened three files for comparing using meld tool > (e.q. Old_version -- Result --

Feature Request: user defined suffix for temp files created by git-mergetool

), we can see only name of temporary files created by mergetool in the labels (e.g. foo_REMOTE -- foo_BASE -- foo_LOCAL) and users (and sometime even we) are confused, which of the files should they edit and save. If you will be so kind and approve this feature request, you will help us to solve

Re: Feature Request: Branch-Aware Submodules

Since I don’t want to change any history in the subproject, to me the most expected behavior would be: git submodule update —-recursive with submodule.*.update set to the command: ``` #!/bin/bash branches=`git branch --points-at "$1"` if [ ! $branches ] ; then git checkout "$1" echo

Re: Feature Request: Branch-Aware Submodules

On Fri, Aug 26, 2016 at 8:12 AM, Hedges Alexander wrote: >> On 25 Aug 2016, at 19:45, Stefan Beller wrote: >> [1] https://github.com/jlehmann/git-submod-enhancements >> which has some attempts for checkout including the submodules. >> I also tried

Re: Feature Request: Branch-Aware Submodules

> On 25 Aug 2016, at 19:45, Stefan Beller wrote: > > +cc Jacob and Lars who work with submodules as well. > > On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander > wrote: >> >> Right now updating a submodule in a topic branch and merging it into

Re: Feature Request: Branch-Aware Submodules

Stefan Beller writes: >>> So you roughly do >>> >>> git checkout -b new-topic >>> # change the submodule to point at the latest upstream version: >>> git submodule update --remote >>> git commit -a -m "update submodule" >>> git checkout master >>> git

Re: Feature Request: Branch-Aware Submodules

On Thu, Aug 25, 2016 at 1:50 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> +cc Jacob and Lars who work with submodules as well. >> >> On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander >> wrote: >>> >>> Right now updating

Re: Feature Request: Branch-Aware Submodules

Stefan Beller writes: > +cc Jacob and Lars who work with submodules as well. > > On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander > wrote: >> >> Right now updating a submodule in a topic branch and merging it into master >> will not change the

Re: Feature Request: Branch-Aware Submodules

"Hedges Alexander" writes: > Right now updating a submodule in a topic branch and merging it into master > will not change the submodule index in master leading to at least two commit > for the same change (one in any active branch). I stopped reading here because I am

Re: Feature Request: Branch-Aware Submodules

+cc Jacob and Lars who work with submodules as well. On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander wrote: > > Right now updating a submodule in a topic branch and merging it into master > will not change the submodule index in master leading to at least two commit >

Feature Request: Branch-Aware Submodules

Dear Git Developers, First of all, thanks for this great project, it has made my life a lot easier as a developer! I'm writing this email to suggest some improvements to git submodules. In my eyes how git handles submodules could be improved to be more intuitive to a novice and require less

Re: Feature request for automatic worktree checkout

On Mon, Jul 18, 2016 at 11:33 AM, Junio C Hamano wrote: > Ehsan Azarnasab writes: > >> Currently if I have a branch checked out in a work-tree, git-checkout >> will show this error message when checking out that branch: >> >> $ git checkout master >>

Re: Feature request for automatic worktree checkout

Ehsan Azarnasab writes: > Currently if I have a branch checked out in a work-tree, git-checkout > will show this error message when checking out that branch: > > $ git checkout master > fatal: 'master' is already checked out at '/home/dashesy/development/feature' > > It

Feature request for automatic worktree checkout

Currently if I have a branch checked out in a work-tree, git-checkout will show this error message when checking out that branch: $ git checkout master fatal: 'master' is already checked out at '/home/dashesy/development/feature' It would be very useful to instead of this error just change the

Re: [feature request] Warn about or prevent --amend commits that don't change anything

Junio C Hamano schrieb: Bergi writes: when nothing is staged in the index then `git commit` warns about this fact with either "nothing to commit, working directory clean" or "no changes added to commit". However, `git commit --amend --no-edit` will happily record a new

Re: [feature request] Warn about or prevent --amend commits that don't change anything

Bergi writes: > when nothing is staged in the index then `git commit` warns about this > fact with either "nothing to commit, working directory clean" or "no > changes added to commit". > However, `git commit --amend --no-edit` will happily record a new > commit that differs in

[feature request] Warn about or prevent --amend commits that don't change anything

Hello, when nothing is staged in the index then `git commit` warns about this fact with either "nothing to commit, working directory clean" or "no changes added to commit". However, `git commit --amend --no-edit` will happily record a new commit that differs in nothing than its commit date

Re: feature request: git svn dommit --preserve-timestamps

On Sat, Jun 11 2016, Eric Wong wrote: > I'm sorry for your situation and hoping you migrate off SVN > entirely, soon :) I've done so, but my customer won't. He wants the code in his svn-repo. > Maybe you could look at how the _use_log_author and > _add_author_from options work. I've forgotten

Re: feature request: git svn dommit --preserve-timestamps

Peter Münster wrote: > On Sat, Jun 11 2016, Eric Wong wrote: > > > The git log after dcommit is tied to the SVN log, > > so git-svn can only reflect changes which appear in SVN. > > You mean, it's impossible, to keep the original timestamps?? It might be; just not easy; and I

Re: feature request: git svn dommit --preserve-timestamps

On Sat, Jun 11 2016, Eric Wong wrote: > The git log after dcommit is tied to the SVN log, > so git-svn can only reflect changes which appear in SVN. You mean, it's impossible, to keep the original timestamps?? > Sidenote: The convention is reply-to-all on lists like > this one

RE: feature request: git svn dommit --preserve-timestamps

Somewhen near June 10, 2016 9:40 PM, Eric Wong wrote: > Peter Münster wrote: > > On Tue, Jun 07 2016, Eric Wong wrote: > > > Peter Münster wrote: > > >> It would be nice, if timestamps could be preserved when rewriting > > >> the git-log. > > > > > >

Re: feature request: git svn dommit --preserve-timestamps

Peter Münster wrote: > On Tue, Jun 07 2016, Eric Wong wrote: > > Peter Münster wrote: > >> It would be nice, if timestamps could be preserved when rewriting the > >> git-log. > > > > Unfortunately, last I checked (a long time ago!), explicitly > > setting

Re: feature request: git svn dommit --preserve-timestamps

On Mon, Jun 06 2016, Peter Münster wrote: > It would be nice, if timestamps could be preserved when rewriting the > git-log. > > Use case: I often make a dcommit after several days of development > (20 or 30 commits), because > - the users of the svn-server don't need it more often; > - and for

Re: feature request: git svn dommit --preserve-timestamps

On Tue, Jun 07 2016, Eric Wong wrote: > Peter Münster wrote: >> It would be nice, if timestamps could be preserved when rewriting the >> git-log. > > Unfortunately, last I checked (a long time ago!), explicitly > setting revprops might require SVN administrators to enable the >

Re: feature request: git svn dommit --preserve-timestamps

Peter Münster wrote: > It would be nice, if timestamps could be preserved when rewriting the > git-log. Unfortunately, last I checked (a long time ago!), explicitly setting revprops might require SVN administrators to enable the feature for the repo. It's been a while and I'm

feature request: git svn dommit --preserve-timestamps

Hi, It would be nice, if timestamps could be preserved when rewriting the git-log. Use case: I often make a dcommit after several days of development (20 or 30 commits), because - the users of the svn-server don't need it more often; - and for the dcommit I need a VPN-connection to a server,

<    1   2   3   4   5   6   >