Feature Request

Feature Request

[Clement Sello Tsetsa]

Greetings;

My name is Clement and I am a second year student at NWU university in
South Africa studying towards a bachelor's degree in information
technology, i just recently learned about Git and it is a fascinating
piece of technology. This is my first time making a feature request
for anything and please excuse me if it is not up to your standards in
any way. Please read the below text as it is the feature request:

When initializing a Git repository, allow specifying file types to
track using the command git init <file>. If no file type is specified,
Git should track all file types by default. Additionally,
automatically create the .gitignore file during initialization, and as
new file types are created, add them to the ignore list. Later, when
adding files to the staging environment, Git will already know which
types to include or ignore using the git add <file> command.

I think the user should not have to create the .gitignore file in the
future if this is implementable.

Kind regards
CS Tsetsa

RE: Feature Request

[rsbecker]

On Thursday, June 20, 2024 8:58 AM. Clement Sello Tsetsa wrote:
>My name is Clement and I am a second year student at NWU university in South
>Africa studying towards a bachelor's degree in information technology, i just
>recently learned about Git and it is a fascinating piece of technology. This is my first
>time making a feature request for anything and please excuse me if it is not up to
>your standards in any way. Please read the below text as it is the feature request:
>
>When initializing a Git repository, allow specifying file types to track using the
>command git init <file>. If no file type is specified, Git should track all file types by
>default. Additionally, automatically create the .gitignore file during initialization, and
>as new file types are created, add them to the ignore list. Later, when adding files to
>the staging environment, Git will already know which types to include or ignore
>using the git add <file> command.
>
>I think the user should not have to create the .gitignore file in the future if this is
>implementable.

Can you clarify what you mean by "file types"? In a cross-platform distributed situation, file types can be interpreted as a combination of file extensions, file encodings, and internal contents. .gitignore only deals with name matching patterns, so cannot reflect inclusion of exclusion of internal content types (for example *.doc with UTF-8 vs. US-ASCII content).

This is an interesting idea but seems to require that git build a generic mechanism for determining file types on all supported platforms and extending .gitignore to represent internal types . This is definitely non-trivial. In Linux, for example, the 'file' command can determine the internal guts of some files, as in:

$ file myfile
myfile:    TNS/X PIC object format,64-bit data model,executable,NonStop OSS target

Note that there is no file extension above.

Can you please clarify what you are looking for in this area?

I would also suggest that you look into both git templates and git hooks. The combination might help cover at least part of this. Specifically, the pre-commit hook might help with management of the .gitignore file.

Regards,
Randall

feature request

[John Rood]

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 this might not be the ideal way to prompt for a commit
message.

1. Many users are used to writing concise one-line commit messages and
would not expect to save a commit message in a multi-line file. Some
users will wonder why they are in a text editor or which file they are
editing. Others may not, in fact, realize at all that a text editor is
what they are in.

2. Many users are not familiar with Vim, and do not understand how to
modify, save, and exit. It is not very considerate to require a user
to learn Vim in order to finish a commit that they are in the middle
of.

The existing behavior should be optional, and there should be two new options:

1. Use a simple inline prompt for a commit message (in the same way
Git might prompt for a username).

2. Automatically assign names for commits in the form of "Merged x into y".

Re: feature request

[Stefan Beller]

On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> 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 is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE,
"C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the
$GIT_EDITOR environment variable, then core.editor configuration, then
$VISUAL, then $EDITOR, and then the default chosen at compile time,
which is usually vi.


So maybe

    git config --global core.editor "nano"

helps in your case?

Re: feature request

[John Rood]

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 <sbeller@google.com> wrote:
> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> 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 is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE,
> "C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the
> $GIT_EDITOR environment variable, then core.editor configuration, then
> $VISUAL, then $EDITOR, and then the default chosen at compile time,
> which is usually vi.
>
>
> So maybe
>
>     git config --global core.editor "nano"
>
> helps in your case?

Re: feature request

[John Rood]

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 Thu, Oct 27, 2016 at 5:05 PM, John Rood <mr.john.rood@gmail.com> wrote:
> 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 <sbeller@google.com> wrote:
>> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> 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 is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE,
>> "C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the
>> $GIT_EDITOR environment variable, then core.editor configuration, then
>> $VISUAL, then $EDITOR, and then the default chosen at compile time,
>> which is usually vi.
>>
>>
>> So maybe
>>
>>     git config --global core.editor "nano"
>>
>> helps in your case?

Re: feature request

[Junio C Hamano]

John Rood <mr.john.rood@gmail.com> 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 whatever you want; I won't let
you edit any mistakes as I am not even a text editor; just hit
RETURN when you are done, as you can only write a single line"
program and set it as your GIT_EDITOR.

I do not know what would happen when you need "git commit --amend",
though.

Re: feature request

[John Rood]

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 <gitster@pobox.com> wrote:
> John Rood <mr.john.rood@gmail.com> 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 whatever you want; I won't let
> you edit any mistakes as I am not even a text editor; just hit
> RETURN when you are done, as you can only write a single line"
> program and set it as your GIT_EDITOR.
>
> I do not know what would happen when you need "git commit --amend",
> though.

Re: feature request

[Junio C Hamano]

John Rood <mr.john.rood@gmail.com> 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 habit to get into, and change to encourage
novice user-base at large to do so is not a good idea.

Re: feature request

[John Rood]

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 leaving messages at
all.


On Thu, Oct 27, 2016 at 5:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> John Rood <mr.john.rood@gmail.com> 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 habit to get into, and change to encourage
> novice user-base at large to do so is not a good idea.

Re: feature request

[Stefan Beller]

On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> 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 user into a Vim window so that they can write a message. There are
> 2 reasons why this might not be the ideal way to prompt for a commit
> message.
>
> 1. Many users are used to writing concise one-line commit messages and
> would not expect to save a commit message in a multi-line file. Some
> users will wonder why they are in a text editor or which file they are
> editing. Others may not, in fact, realize at all that a text editor is
> what they are in.

Look at the -m option of git commit,

git commit -a -m "look a commit with no editor, and a precise one line message"

I do not advocate this use though, as I think commit messages should be
more wordy.

>
> 2. Many users are not familiar with Vim, and do not understand how to
> modify, save, and exit. It is not very considerate to require a user
> to learn Vim in order to finish a commit that they are in the middle
> of.

That is true, but vi is like the most available editor as a relict
from ancient times;
as you are on Windows, maybe notepad is the best on that platform.

Maybe file a bug/issue at https://github.com/git-for-windows to change
the default?

>
> The existing behavior should be optional, and there should be two new options:
>
> 1. Use a simple inline prompt for a commit message (in the same way
> Git might prompt for a username).
>
> 2. Automatically assign names for commits in the form of "Merged x into y".

Re: feature request

[John Rood]

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 isn't issuing the "git commit" command, and so
he/she doesn't have the opportunity to use the -m flag.

On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller <sbeller@google.com> wrote:
> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> 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 user into a Vim window so that they can write a message. There are
>> 2 reasons why this might not be the ideal way to prompt for a commit
>> message.
>>
>> 1. Many users are used to writing concise one-line commit messages and
>> would not expect to save a commit message in a multi-line file. Some
>> users will wonder why they are in a text editor or which file they are
>> editing. Others may not, in fact, realize at all that a text editor is
>> what they are in.
>
> Look at the -m option of git commit,
>
> git commit -a -m "look a commit with no editor, and a precise one line message"
>
> I do not advocate this use though, as I think commit messages should be
> more wordy.
>
>>
>> 2. Many users are not familiar with Vim, and do not understand how to
>> modify, save, and exit. It is not very considerate to require a user
>> to learn Vim in order to finish a commit that they are in the middle
>> of.
>
> That is true, but vi is like the most available editor as a relict
> from ancient times;
> as you are on Windows, maybe notepad is the best on that platform.
>
> Maybe file a bug/issue at https://github.com/git-for-windows to change
> the default?
>
>>
>> The existing behavior should be optional, and there should be two new options:
>>
>> 1. Use a simple inline prompt for a commit message (in the same way
>> Git might prompt for a username).
>>
>> 2. Automatically assign names for commits in the form of "Merged x into y".

Re: feature request

[Junio C Hamano]

John Rood <mr.john.rood@gmail.com> writes:

> On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> 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 user into a Vim window so that they can write a message. There are
>>> 2 reasons why this might not be the ideal way to prompt for a commit
>>> message.
>>>
>>> 1. Many users are used to writing concise one-line commit messages and
>>> would not expect to save a commit message in a multi-line file. Some
>>> users will wonder why they are in a text editor or which file they are
>>> editing. Others may not, in fact, realize at all that a text editor is
>>> what they are in.
>>
>> Look at the -m option of git commit,
>>

[administrivia: do not top post]

> 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 isn't issuing the "git commit" command, and so
> he/she doesn't have the opportunity to use the -m flag.

There is --no-edit there.

Re: feature request

[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

Re: feature request

[Johannes Schindelin]

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 in Git for Windows that converts
line endings transparently before and after calling the real notepad.exe.

Ciao,
Johannes

Re: feature request

[Philip Oakley]

From: "David Lang" <david@lang.hm>
> 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 standard part of Windows.

[core]
 editor = 'C:/Program 
Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noplugin

.. is one of the standard StackOverflow recipes.
--
Philip 

feature request

[Jay Townsend]

Hi everyone,


Just would like to request a security feature to help secure peoples 
github accounts more by supporting 2 factor authentication like the 
yubikey more information can be found from this link 
www.yubico.com/develop/ and googles 2 factor authentication. Hope it 
gets implemented as I think it would make a great feature

Re: feature request

[James Nylen]

On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend <townsend891@hotmail.com> wrote:
> Hi everyone,
>
> Just would like to request a security feature to help secure peoples github
> accounts more by supporting 2 factor authentication like the yubikey more
> information can be found from this link www.yubico.com/develop/ and googles
> 2 factor authentication. Hope it gets implemented as I think it would make a
> great feature

This would most likely be something that users would set up with their
SSH client, and GitHub would have to provide support for it on their
servers as well.  It shouldn't require any changes to git.  Here is an
example of how this could be done:

http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/

I like the idea, and I would probably use it if it were available.
Jeff, what do you think?

Re: feature request

[Jeff King]

On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:

> > Just would like to request a security feature to help secure peoples github
> > accounts more by supporting 2 factor authentication like the yubikey more
> > information can be found from this link www.yubico.com/develop/ and googles
> > 2 factor authentication. Hope it gets implemented as I think it would make a
> > great feature
> 
> This would most likely be something that users would set up with their
> SSH client, and GitHub would have to provide support for it on their
> servers as well.  It shouldn't require any changes to git.  Here is an
> example of how this could be done:
> 
> http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/
> 
> I like the idea, and I would probably use it if it were available.
> Jeff, what do you think?

When you are talking about something like GitHub, there are a lot of
times and methods to authenticate: logging into the web service, using
an ssh key for git-over-ssh, using a password for git-over-http, tokens
for API access, and probably more that I can't think of right now.

Logging into the web page can add 2-factor auth pretty easily, since
it's a web form.

Git over ssh can also do so without changes to git, because we rely on
ssh to do all of the interactive authentication.  However, I wonder how
many people would be that interested in it, as key auth already provides
some degree of two factor protection, assuming you protect your key with
a passphrase (the threat model is different, of course, because the two
factors are happening on the client, and do not involve the server at
all).

Git over http _would_ need git client support, since it asks the user
for the password directly. Or at the very least some clever encoding
scheme where your password becomes "<real_password>:<2FA_pass>" or
something. But I'm not sure that people want raw two-factor
authentication for pushes. It's a giant pain, and people were recently
happy to move to password-less pushes via credential helpers; this would
move in the opposite direction.

The thing that makes 2FA usable in the web browser setting is that you
authenticate only occasionally, and get a token (i.e., a cookie) from
the server that lets you have a longer session without re-authenticating.
I suspect a usable 2FA scheme for http pushes would involve a special
credential helper that did the 2FA auth to receive a cookie on the first
use, cached the cookie, and then provided it for subsequent auth
requests. That would not necessarily involve changing git, but it would
mean writing the appropriate helper (and the server side to match). I
seem to recall Shawn mentioning that Google does something like this
internally, but I don't know the details[1].

So yes. It's an interesting direction to go, but I think there's a fair
bit of work, and it needs to be broken down into how specific services
will interact with it. The first step would probably be securing the web
login with it, since that is the easiest one to do, and also the most
powerful interface (the other ones just let you push or fetch code; the
web interface lets you delete repos, change passwords, access billing,
etc).

But that first step is something that would happen entirely at GitHub,
with no client support necessary. We don't have schedules or plans, and
we don't promise features. So I can neither confirm nor deny that people
are working on it right now.

-Peff

[1] I don't know if Google's system is based on the Google Authenticator
    system. But it would be great if there could be an open,
    standards-based system for doing 2FA+cookie authentication like
    this. I'd hate to have "the GitHub credential helper" and "the
    Google credential helper". I'm not well-versed enough in the area to
    know what's feasible and what the standards are.

Re: feature request

[Drew Northup]

On Mon, Feb 18, 2013 at 3:45 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:
>> > Just would like to request a security feature to help secure peoples github
>> > accounts more by supporting 2 factor authentication like the yubikey more
>> > information can be found from this link www.yubico.com/develop/ and googles
>> > 2 factor authentication. Hope it gets implemented as I think it would make a
>> > great feature
>>
>> I like the idea, and I would probably use it if it were available.
>> Jeff, what do you think?
> [1] I don't know if Google's system is based on the Google Authenticator
>     system. But it would be great if there could be an open,
>     standards-based system for doing 2FA+cookie authentication like
>     this. I'd hate to have "the GitHub credential helper" and "the
>     Google credential helper". I'm not well-versed enough in the area to
>     know what's feasible and what the standards are.

I don't know what the specific infrastructure they (Google's
engineers) are using is (something written in python if I'm not
mistaken), but @$dayjob we've managed to authenticate to Google Apps
using SAML 1.1 & SAML2 wrappers "living" in both CAS and Shibboleth.
SAML is a standard and is supported (in whole or in part) by a lot of
systems and SSOs out there. Given the way that systems like that work
I don't see Git authenticating that way any time soon (but I've been
surprised before).

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59

Re: feature request

[Shawn Pearce]

On Mon, Feb 18, 2013 at 12:45 PM, Jeff King <peff@peff.net> wrote:
>
> The thing that makes 2FA usable in the web browser setting is that you
> authenticate only occasionally, and get a token (i.e., a cookie) from
> the server that lets you have a longer session without re-authenticating.

Right, otherwise you spend all day typing in your credentials and
syncing with the 2nd factor device.

> I suspect a usable 2FA scheme for http pushes would involve a special
> credential helper that did the 2FA auth to receive a cookie on the first
> use, cached the cookie, and then provided it for subsequent auth
> requests. That would not necessarily involve changing git, but it would
> mean writing the appropriate helper (and the server side to match). I
> seem to recall Shawn mentioning that Google does something like this
> internally, but I don't know the details[1].
...
> [1] I don't know if Google's system is based on the Google Authenticator
>     system. But it would be great if there could be an open,
>     standards-based system for doing 2FA+cookie authentication like
>     this. I'd hate to have "the GitHub credential helper" and "the
>     Google credential helper". I'm not well-versed enough in the area to
>     know what's feasible and what the standards are.

Yes, it is based on the Google Authenticator system, but that's not
relevant to how Git works with it. :-)

We have a special "git-remote-sso" helper we install onto corporate
workstations. This allows Git to understand the "sso://" protocol.
git-remote-sso is a small application that:

- reads the URL from the command line,
- makes sure a Netscape style cookies file has a current cookie for
the named host,
   - acquires or updates cookie if necessary
- rewrites the URL to be https://
- execs `git -c http.cookiefile=$cookiefile remote-https $URL`

The way 2FA works is the user authenticates to a special internal SSO
management point in their web browser once per period (I decline to
say how often but its tolerable). Users typically are presented this
SSO page anyway by other applications they visit, or they bookmark the
main entry point. A Chrome or Firefox extension has been installed and
authorized to steal cookies from this host. The extension writes the
user's cookie to a local file on disk. Our git-remote-sso tool uses
this cookie file to setup per-host cookies on demand within the
authentication period.

Horrifically hacky. It would be nice if this was more integrated into
Git itself, where the cookies could be acquired/refreshed through the
credential helper system rather than wrapping git-remote-https with a
magical URL. I am a fan of the way our extension manages to get the
token conveyed automatically for me. Much easier than the OAuth
flows[2], but harder to replicate in the wild. Our IT group makes sure
the extension is installed on workstations as part of the base OS
image.

[2] https://developers.google.com/storage/docs/gsutil_install#authenticate

feature request

[Angelo Borsotti]

Hello,

some VCS, e.g. ClearCase, allow to control the fetching of files so as
to warn, or
disallow parallel changes to the same files.
As of today, there is no way to implement the same kind of workflow with git
because there are no fetch hooks.
Would it be a good idea to provide them?

-Angelo Borsotti

Re: feature request

[Andrew Ardill]

On 16 October 2012 22:36, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:
>
> Hello,
>
> some VCS, e.g. ClearCase, allow to control the fetching of files so as
> to warn, or
> disallow parallel changes to the same files.
> As of today, there is no way to implement the same kind of workflow with
> git
> because there are no fetch hooks.
> Would it be a good idea to provide them?
>
> -Angelo Borsotti

It seems like you want to be able to lock a file for editing once
someone has 'checked-out' the file. This really only makes sense for
binary files (or files which there is no straightforward way to merge)
as otherwise you are throwing away the usefulness of git without any
gain. Git is designed so that multiple people can work on a file at
the same time. Easy merging means that collating those changes is an
easy task, and so locking a file has no use. If a file cannot be
easily merged then it does make sense to lock the file. Is this what
you need to do, or is there some other reason for wanting a lock?

In any case, locking a file is a hard thing to do right in a
distributed system, and doesn't really make sense (although it may be
useful!) When you clone a git repository you have the entire history
of the repository on your computer. What does it mean to have a locked
file? Does the file get deleted from everyone's repository every time
someone else locks it? That would seem silly. Perhaps everyone simply
can't write to that file once it has been locked - how do you impose
that restriction in a distributed system (you can't)?

Instead you can only refuse pushes that change the locked file (which
is normal - you would have to force the push for any non fast-forward
changes), and you can try to warn users that somebody else has locked
the file. This warning system might be doable in some fashion, by
using hooks to write the locked files to a text file somewhere and
checking that, however it would be near impossible to get right or
would hamstring the distributed nature of git by forcing constant
server checks.

Instead of continuing making the point here, let me point you towards
some other discussions around file locks, in particular how git
handles binary files. You should be able to find many more, but as a
starter, look at [1] and [2].

In general, I would reconsider why two users shouldn't be able to
change the same file at the same time.

Regards,

Andrew Ardill

[1] http://stackoverflow.com/questions/119444/locking-binary-files-using-git-version-control-system
[2] http://git.661346.n2.nabble.com/Lock-binairy-files-in-Git-td2422894.html

Re: feature request

[Angelo Borsotti]

Hi Andrew,

one nice thing is to warn a developer that wants to modify a source
file, that there is somebody else changing it beforehand. It is nicer
than discovering that at push time.
Take into account that there are changes in files that may be
incompatible to each other, or that can be amenable to be
automatically merged producing wrong results. So, knowing it could
help.

-Angelo

Re: feature request

[Sitaram Chamarty]

On Tue, Oct 16, 2012 at 10:57 PM, Angelo Borsotti
<angelo.borsotti@gmail.com> wrote:
> Hi Andrew,
>
> one nice thing is to warn a developer that wants to modify a source
> file, that there is somebody else changing it beforehand. It is nicer
> than discovering that at push time.

Andrew:

also see http://sitaramc.github.com/gitolite/locking.html for a way to
do file locking (and enforce it) using gitolite.

This does warn, as long as the user remembers to try to acquire a lock
before working on a binary file.  (You can't get around that
requirement on a DVCS, sorry!)

> Take into account that there are changes in files that may be
> incompatible to each other, or that can be amenable to be
> automatically merged producing wrong results. So, knowing it could
> help.
>
> -Angelo
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Sitaram

Re: feature request

[Andrew Ardill]

On 17 October 2012 04:27, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:
> Hi Andrew,
>
> one nice thing is to warn a developer that wants to modify a source
> file, that there is somebody else changing it beforehand. It is nicer
> than discovering that at push time.
> Take into account that there are changes in files that may be
> incompatible to each other, or that can be amenable to be
> automatically merged producing wrong results. So, knowing it could
> help.
>
> -Angelo

If you simply want to know when a file has been changed by someone
else, git already has this capability, but as you note it only occurs
when you try to push. Unless you force push, you have to merge changes
before committing to upstream. In a distributed situation you can only
inform the user when they 'touch-base' with the server, and if that is
what you want than one of the locking systems others have proposed
might be a good choice.

There are two concerns to deal with here. The first is when any
conflicts at all will cause problems, as there is no way to merge
them. This often happens with binary files, and is a good reason to
use a locking system. The second concern is situations where a merge
happens 'silently' (i.e. no conflicts) thus allowing potential logic
bugs to be introduced even though semantically the merge was fine. For
this situation the best option is to require whoever is merging to
check the merge output for logical errors. This has to happen anyway,
as it is possible for logical errors to be introduced across different
files, although it's probably more common to see logic conflicts
within the one file. To make it easier to discover such changes early
in the process you could write a tool that did some (or all) of the
following:
1. Automatically fetch changes from remote repositories at a regular interval.
2. Compare files changed in the working tree and index to changes
fetched from remote repositories. This would need to find the merge
base of the two and compare files touched since then.
3. Notify the user of the files that have been changed through some fashion.
4. Automatically push changes to a 'wip' branch so that others can see
what you are modifying. Alternatively, automatically publish a list of
changed files for the same purpose, though this seems a lot more hacky
(though both options are surely hacky).

2 and 3 could be combined into a single tool run whenever the user
wants to check for potential logic changes down the track. Automating
it would allow for this information to be communicated a bit faster.
Running it after each fetch would be a nice to have. Pushing the work
in progress branch is something I am not sure is a good idea, but it
would be the only way to know when someone else is working on
something before they commit and push it manually. Pushing a single
file with files being worked on is less invasive, but would require
the other aspects of the tool to use it as well (hence forming a
stronger coupling and reducing the usefulness of the other components
as standalone tools).


There is no way that I know of to force merge to stop every time the
file is changed on both theirs and ours (regardless of whether or not
it is an actual conflict or not). It could potentially be done with a
pre-merge hook, but no such hook exists to my knowledge. If this were
implemented, using it would make merging a potentially tiresome
affair, however I could see its usefulness for people who were very
concerned about introducing logic errors with merges on the same file.

The best solution is in my opinion to check what is going to be merged
before you merge it, but a tool to warn that someone else is modifying
the same file would have its uses.

Regards,

Andrew Ardill

Re: feature request

[Christian Thaeter]

Am Tue, 16 Oct 2012 13:36:04 +0200
schrieb Angelo Borsotti <angelo.borsotti@gmail.com>:

> Hello,
> 
> some VCS, e.g. ClearCase, allow to control the fetching of files so as
> to warn, or
> disallow parallel changes to the same files.
> As of today, there is no way to implement the same kind of workflow
> with git because there are no fetch hooks.
> Would it be a good idea to provide them?


I've actually implemented a 'git lock' command to lock pathnames from
concurrent editing for a customer. Normally one would say this is a
rather ill and ugly feature for git but there where some reasons to do
it anyways (imagine robots crashing into each other on a production
line because of bad (developer-)communication).

The code is GPL and I can distribute it, but I didn't consider it ready
for an open announcement yet. Noteworthy some problems with msys led
to some ugly solution (the uniq command doesn't know the -z option
there).

I hope this might be useful to you. I'd also like to get contributions
and fixes if there are any problems I am not aware of.

Short into; the doc:

 http://git.pipapo.org/?p=git;a=blob_plain;f=Documentation/git-lock.txt;h=dcc7a5c34dea657ab5819e8def54e154d5d97219;hb=25ee09cf35daa03a7c2ef10537561a50db2d17b2

the code is available at

 git://git.pipapo.org/git

in the 'ct/git-lock' branch.

It is a bit fallen behind the current git version, I will update/merge
it sometime next (to keep in par with msysgit, thats what is required
here)

	Christian




> 
> -Angelo Borsotti
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html