Introduction

To define a form in django, a developer has to create a class which extends django.forms.Form and has a number of attributes extending from django.forms.Field. This makes it very easy for the developer to create static forms, but creating dynamic forms whose fields can be changed depending on the data contributed by the users of the application is not so obvious.

Of course, some people may argue that they can do whatever they want just by spitting html input tags to their templates, however this totally violates DRY and any serious django developer would prefer to write MUMPS than creating html dynamically.

The implementation I will present here had been developed for an old project: In that project there was a number of services which could be edited dynamically by the moderators. For each service, the moderators would generate a questionnaire to get input from the users which would be defined using JSON. When the users needed to submit information for each service, a dynamic django form would be generated from this JSON and the answers would be saved to no-SQL database like MongoDB.

Describing a django form in JSON

A JSON described django form is just an array of field JSON objects. Each field object has three required attributes: name which is the keyword of the field, label which is how the label of the field and type which is the type of the input of that field. The supported types are text, textarea, integer, radio, select, checkbox. Now, depending on the type of the field, there could be also some more required attributes, for instace text has a max_length attribute and select has a choices attribute (which is an array of name/value objects). Also there are two optional attributes, required with a default value of False and help_text with a default value of ”.

As you can understand these map one by one to the corresponding attributes of the actual django form fields. An example containing a complete JSON described form is the following:

[
    {
        "name": "firstname",
        "label": "First Name",
        "type": "text",
        "max_length": 25,
        "required": 1
    },
    {
        "name": "lastname",
        "label": "Last Name",
        "type": "text",
        "max_length": 25,
        "required": 1
    },
    {
        "name": "smallcv",
        "label": "Small CV",
        "type": "textarea",
        "help_text": "Please insert a small CV"
    },
    {
        "name": "age",
        "label": "Age",
        "type": "integer",
        "max_value": 200,
        "min_value": 0
    },
    {
        "name": "marital_status",
        "label": "Marital Status",
        "type": "radio",
        "choices": [
            {"name": "Single", "value":"single"},
            {"name": "Married", "value":"married"},
            {"name": "Divorced", "value":"divorced"},
            {"name": "Widower", "value":"widower"}
        ]
    },
    {
        "name": "occupation",
        "label": "Occupation",
        "type": "select",
        "choices": [
            {"name": "Farmer", "value":"farmer"},
            {"name": "Engineer", "value":"engineer"},
            {"name": "Teacher", "value":"teacher"},
            {"name": "Office Clerk", "value":"office_clerk"},
            {"name": "Merchant", "value":"merchant"},
            {"name": "Unemployed", "value":"unemployed"},
            {"name": "Retired", "value":"retired"},
            {"name": "Other", "value":"other"}
        ]
    },
    {
        "name": "internet",
        "label": "Internet Access",
        "type": "checkbox"
    }
]

The above JSON string can be easily converted to an array of dictionaries with the following code:

import json
fields=json.loads(json_fields)

Creating the form fields

The most import part in the django dynamic form creation is to convert the above array of field-describing dictionaries to actual objects of type django.forms.Field.

To help with that I implemented a class named FieldHandler which gets an array of field dictionaries and after initialization will have an attribute named formfields which will be a dictionary with keys the names of each field an values the corresponding django.forms.Field objects. The implementation is as follows:

import django.forms

class FieldHandler():
    formfields = {}
    def __init__(self, fields):
        for field in fields:
            options = self.get_options(field)
            f = getattr(self, "create_field_for_"+field['type'] )(field, options)
            self.formfields[field['name']] = f

    def get_options(self, field):
        options = {}
        options['label'] = field['label']
        options['help_text'] = field.get("help_text", None)
        options['required'] = bool(field.get("required", 0) )
        return options

    def create_field_for_text(self, field, options):
        options['max_length'] = int(field.get("max_length", "20") )
        return django.forms.CharField(**options)

    def create_field_for_textarea(self, field, options):
        options['max_length'] = int(field.get("max_value", "9999") )
        return django.forms.CharField(widget=django.forms.Textarea, **options)

    def create_field_for_integer(self, field, options):
        options['max_value'] = int(field.get("max_value", "999999999") )
        options['min_value'] = int(field.get("min_value", "-999999999") )
        return django.forms.IntegerField(**options)

    def create_field_for_radio(self, field, options):
        options['choices'] = [ (c['value'], c['name'] ) for c in field['choices'] ]
        return django.forms.ChoiceField(widget=django.forms.RadioSelect,   **options)

    def create_field_for_select(self, field, options):
        options['choices']  = [ (c['value'], c['name'] ) for c in field['choices'] ]
        return django.forms.ChoiceField(  **options)

    def create_field_for_checkbox(self, field, options):
        return django.forms.BooleanField(widget=django.forms.CheckboxInput, **options)

As can be seen, in the __init__ method, the get_options method is called first which returns a dictionary with the common options (label, help_text, required). After that, depending on the type of each field the correct method will be generated with getattr(self, "create_field_for_"+field['type'] ) (so if type is text this will return a reference to the create_field_for_text method) and then called passing the field dictinary and the options returned from get_options. Each one of the create_field_for_xxx methods will extract the required (or optional) attributes for the specific field type, update options and initialize the correct Field passing the options as kwargs. Finally the formfields attribute will be updated with the name and Field object.

Creating the actual form

To create the actual dynamic django.forms.Form I used the function get_form which receives a string with the json description, parses it to a python array, creates the array of fields with the help of FieldHandler and then generates the Form class with type passing it django.forms.Form as a parent and the array of django.forms.Field from FieldHandler as attributes:

def get_form(jstr):
    fields=json.loads(jstr)
    fh = FieldHandler(fields)
    return type('DynaForm', (django.forms.Form,), fh.formfields )

Using the dynamic form

The result of get_form can be used as a normal form class. As an example:

import dynaform

def dform(request):
    json_form = get_json_form_from_somewhere()
    form_class = dynaform.get_form(json_form)
    data = {}
    if request.method == 'POST':
        form = form_class(request.POST)
        if form.is_valid():
            data = form.cleaned_data
    else:
        form = form_class()

    return render_to_response( "dform.html", {
        'form': form,  'data': data,
    }, RequestContext(request) )

So, we have to get our JSON form description from somewhere (for instance a field in a model) and then generate the form class with get_form. After that we follow the normal procedure of checking if the request.method is POST so we pass the POST data to the form and check if it is value or we just create an empty form. As a result we just pass the data that was read from the form to the view for presentation.

Introduction

One common requirement in an organization is to separate users in authorities (meaning departments / units / branches etc) and each authority have its own data. So users belonging to the “Athens Branch” won’t be able to edit data submitted from users of the “Thessaloniki Branch”.

This is a special case of the more general row-level-security in which each instance of a domain object will have an ACL. Row-level-security would need a many-to-many relation between object instances and authorities, something that would be overkill in our case.

Authority data is also a more general case of the user-data meaning that each user can have access to data that he inserts in the system. Implementing user-data is easy using the techniques we will present below.

We have to notice that the django permissions do not support our requirements since they define security for all instances of a model.

Defining authorities

In order to have custom authorities I propose first of all to add an Authority model that would define the authority. Even if your authorities only have a name I believe that adding the Authority model would be beneficial. Now, there are many ways to separate normal django users (django.contrib.auth.models.User) to authorities:

class CustomAuthorityMiddleware:
  def process_request(self, request):
    if not request.session.get('authority'):
      authority = get_the_authority(request.user)
      request.session['authority']=authority

class Profile(models.Model):
  user = models.OneToOneField('django.auth.User')
  authority = models.ForeignKey('authorities.Authority', blank=True, null=True )

class Authority(models.Model):
  id = models.IntegerField(primary_key = True)
  name = models.CharField(max_length=64, )
  auth_type = models.CharField(max_length=16, )

Adding authority data

To define authority data you have to add a field to your model that would define its authority, for instance like this:

class AuthorityData(models.Model):
  authority = models.ForeignKey('authorities.Authority', editable=False,)

This field should not be editable (at least by your end users) because they shouldn’t be able to change the authority of the data they insert.

If you want to have user-data then just add a models.ForeignKey('django.auth.User', editable=False)

Now, your Create and Update Class Based Views have to pass the request to your forms and also your Detail and Update CBV should allow only getting objects that belong to the authority of the user:

class AuthorityDataCreateView(CreateView):
  model=models.AuthorityData

  def get_form_kwargs(self):
      kwargs = super(AuthorityDataCreateView, self).get_form_kwargs()
      kwargs.update({'request': self.request})
      return kwargs

class AuthorityDataDetailView(DetailView):
  def get_object(self, queryset=None):
      obj = super(AuthorityDataDetailView, self).get_object(queryset)
      if if not user_has_access(obj, self.request):
          raise Http404(u"Access Denied")
      return obj

class AuthorityDataUpdateView(UpdateView):
  model=models.AuthorityData

  def get_form_kwargs(self):
      kwargs = super(AuthorityDataUpdateView, self).get_form_kwargs()
      kwargs.update({'request': self.request})
      return kwargs

  def get_object(self, queryset=None):
      obj = super(AuthorityDataUpdateView, self).get_object(queryset)
      if if not user_has_access(obj, self.request):
          raise Http404(u"Access Denied")
      return obj

Your ModelForm can now use the request to get the Authority and set it (don’t forget that you should not use Meta.exclude but instead use Meta.include!):

class AuthorityDataModelForm(forms.ModelForm):
    class Meta:
      model = models.AuthorityData
      exclude = ('authority',)

    def __init__(self, *args, **kwargs):
      self.request = kwargs.pop('request', None)
      super(ActionModelForm, self).__init__(*args, **kwargs)


    def save(self, force_insert=False, force_update=False, commit=True):
      obj = super(AuthorityDataModelForm, self).save(commit=False)
      if obj:
          obj.authority = get_user_authority(self.request)
          obj.save()
      return obj

The previous work fine for Create/Detail/Update CBVs but not for ListsViews. List views querysets and in general all queries to the object have to be filtered through authority.

class AuthorityDataListView(ListView):
  def get_queryset(self):
    queryset = super(AuthorityDataModelForm, self).get_queryset()
    return queryset.filter(authority = get_user_authority(request))

Conclusion

Using the above techniques we can define authority (or just user) data. Your AuthorityData should have a ForeignKey to your Authority and you have configure your queries, ModelForms and CBVs to use that. If you have more than one models that belong to an authority and want to stay DRY then you’d need to define all the above as mixins.

Introduction

One very useful component of the spring java framework is spring-security since it allows consistent usage of various security providers for authentication and authorization. Although I’ve found a great number of basic spring-security tutorials on the internet, I wasn’t able to find a complete solution for my own requirements:

Logging in with LDAP but configuring the authorities [*] of the logged in user with the help of a custom method and not through LDAP.

I think that the above is a common requirement in many organizations: There is a central LDAP repository in which the usernames and passwords of the users are stored, but the groups of the users are not stored there. Or maybe the groups that are actually stored in the LDAP cannot be transformed easily to application specific groups for each application.

You may find the working spring project that uses ldap and a custom groups populator here: https://github.com/spapas/SpringLdapCustomAuthorities/

A basic spring security setup

I’ve created a very basic setup for spring-security for a spring-mvc project. Please take a look here for a more thorough explanation of a simple spring-security project http://www.mkyong.com/spring-security/spring-security-hello-world-example/ and here http://www.codeproject.com/Articles/253901/Getting-Started-Spring-Security for a great explanation of the various spring-security classes.

In my setup there is a controller that defines two mappings, the “/” which is the homepage that has a link to the “/enter” and the “/enter” which is an internal page in which only authorized users have access. When the user clicks on “enter” he will be represented with a login form first. If the use logs in successfully, the enter.jsp will list the username and the authorities of the logged in user through the following spring-security tags:

<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
[...]
Username: <sec:authentication property="principal.username" /><br />
Authorities: <sec:authentication property="principal.authorities"/><br />

The authentication provider is an in memory service in which the username, password and authorities of each user are defined in the XML. So this is a simple spring-security example that can be found in a number of places on the internet. The security rules, login form and the authentication provider are configured with the following security-config.xml:

<beans:beans xmlns="http://www.springframework.org/schema/security"
   xmlns:beans="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
                   http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
                   http://www.springframework.org/schema/security
                   http://www.springframework.org/schema/security/spring-security-3.1.xsd">

   <http pattern="/static/**" security="none" />

   <http use-expressions="true">
       <intercept-url pattern="/" access="permitAll" />
       <intercept-url pattern="/enter" access="hasRole('user')" />
       <intercept-url pattern="/**" access="denyAll" />
       <form-login default-target-url="/" />
       <logout  logout-success-url="/" />
   </http>

   <authentication-manager>
       <authentication-provider>
           <user-service>
               <user name="spapas" password="123" authorities="admin, user, nonldap" />
               <user name="serafeim" password="123" authorities="user" />
           </user-service>
       </authentication-provider>
   </authentication-manager>

</beans:beans>

When we run this application and go to the /enter, we will get the following output:

Username: spapas

Authorities: [admin, nonldap, user]

Spring security LDAP with custom authorities

The previous application can be modified to login through LDAP and get the authorities from a custom class. The main differences are in the pom.xml which adsd the spring-security-ldap dependency, the addition of a CustomLdapAuthoritiesPopulator.java which does the actual mapping of username to authority and various changes to the security-config.xml.

As you will see we had to define our security beans mainly using spring beans and not using the various elements from security namespace like <ldap-server> and <ldap-authentication-provder>. For a good tutorial on using these elements and ldap in spring security in general check these out: http://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html and http://krams915.blogspot.gr/2011/01/spring-security-mvc-using-ldap.html.

<beans:beans xmlns="http://www.springframework.org/schema/security"
   xmlns:beans="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
                   http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
                   http://www.springframework.org/schema/security
                   http://www.springframework.org/schema/security/spring-security-3.1.xsd">

   <http pattern="/static/**" security="none" />

   <http use-expressions="true" >
     <intercept-url pattern="/" access="permitAll" />
     <intercept-url pattern="/enter" access="hasRole('user')" />
     <intercept-url pattern="/**" access="denyAll" />
     <form-login default-target-url="/" />
     <logout  logout-success-url="/" />
   </http>

   <beans:bean id="contextSource"
         class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
     <beans:constructor-arg value="ldap://login.serafeim.gr:389/dc=serafeim,dc=gr"/>
     <beans:property name="anonymousReadOnly" value="true"/>
   </beans:bean>

   <beans:bean
         id="userSearch"
         class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
     <beans:constructor-arg index="0" value=""/>
     <beans:constructor-arg index="1" value="(uid={0})"/>
     <beans:constructor-arg index="2" ref="contextSource" />
   </beans:bean>

   <beans:bean
         id="ldapAuthProvider"
         class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
     <beans:constructor-arg>
       <beans:bean class="org.springframework.security.ldap.authentication.BindAuthenticator">
         <beans:constructor-arg ref="contextSource"/>
         <beans:property name="userSearch" ref="userSearch" />
         <!--
         <beans:property name="userDnPatterns">
           <beans:list><beans:value>uid={0},ou=People</beans:value></beans:list>
         </beans:property>
         -->
       </beans:bean>
     </beans:constructor-arg>
     <beans:constructor-arg>
       <beans:bean class="gr.serafeim.springldapcustom.CustomLdapAuthoritiesPopulator" />
     </beans:constructor-arg>
   </beans:bean>

   <authentication-manager>
     <authentication-provider ref="ldapAuthProvider" />
   </authentication-manager>

</beans:beans>

So, in the above configuration we’ve defined three spring beans: contextSource, userSearch and ldapAuthProvider. The <authentication-manager> element uses the ldapAuthProvider as an authentication provider. Below we will explain these beans:

package gr.serafeim.springldapcustom;

import java.util.Collection;
import java.util.HashSet;
import org.springframework.ldap.core.DirContextOperations;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.security.ldap.userdetails.LdapAuthoritiesPopulator;
import org.springframework.stereotype.Component;

@Component
public class CustomLdapAuthoritiesPopulator implements LdapAuthoritiesPopulator {
       @Override
       public Collection<? extends GrantedAuthority> getGrantedAuthorities(
                       DirContextOperations userData, String username) {
               Collection<GrantedAuthority> gas = new HashSet<GrantedAuthority>();
               if(username.equals("spapas")) {
                       gas.add(new SimpleGrantedAuthority("admin"));
               }
               gas.add(new SimpleGrantedAuthority("user"));
               return gas;
       }
}

Conclusion

In the previous a complete example of configuring a custom authorities populator was represented. Using this configuration we can login through the LDAP server of our organization but use application specific roles for our logged-in users.

Introduction

A branch is a very interesting git feature. With this you may have more than one branches in the same repository. The main usage of this feature would be to create different versions of your source code to parallel test development of different features. When the development of each of these features has been finished then the different versions would need to be combined (or merged) to a single version. Of course, merging is not always the result of branching - some branches may exist indefinitely or other may just be deleted without merging.

I will try to experiment with it and comment on the results.

Creating a new git repository

Let’s start by creating a new git repository:

D:\>mkdir testgit
D:\>cd testgit
D:\testgit>echo contents 11 > file1.txt
D:\testgit>echo contents 222 > file2.txt
D:\testgit>echo 3333 > file2.txt
D:\testgit>copy con file3.txt
line 1 of file 3

line 3 of file 3

test

line 7 of file 3
^Z
       1 files copied.

D:\testgit>git init
Initialized empty Git repository in D:/testgit/.git/
D:\testgit>git add .
D:\testgit>git commit -m Initial
[master (root-commit) 96ca9af] Initial
 3 files changed, 9 insertions(+)
 create mode 100644 file1.txt
 create mode 100644 file2.txt
 create mode 100644 file3.txt

To see the branch we are in we can use the git branch command. Also git status outputs the current branch:

D:\testgit>git status
# On branch master
nothing to commit, working directory clean
D:\testgit>git branch
* master

So, it seems that when we create a new repository, a “master” branch is created.

Branching

Lets create a new branch and change our working branch to it:

D:\testgit>git branch slave
D:\testgit>git branch
* master
  slave
D:\testgit>git checkout slave
Switched to branch 'slave'
D:\testgit>git branch
  master
* slave

We can see that now the slave branch is the current one. Let’s do some changes and add commit them to the slave branch:

D:\testgit>git branch
  master
* slave
D:\testgit>echo new file1 contents > file1.txt
D:\testgit>git commit -m "Slave modification"
[slave b6083ad] Slave modification
 1 file changed, 1 insertion(+), 1 deletion(-)
D:\testgit>git checkout master
Switched to branch 'master'
D:\testgit>more file1.txt
contents 11
D:\testgit>git checkout slave
Switched to branch 'slave'
D:\testgit>more file1.txt
new file1 contents

So the contents of file1.txt in the branch master is contents 11 while the contents of the same file in the branch slave is new file1 contents.

An interested behaviour is what happens with uncommit changes when changing branches. Let’s try deleting a file:

D:\testgit>del file2.txt
D:\testgit>git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    file2.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
D:\testgit>git checkout slave
D       file2.txt
Switched to branch 'slave'
D:\testgit>git status
# On branch slave
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    file2.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
D:\testgit>git add -A
D:\testgit>git status
# On branch slave
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    file2.txt
#
D:\testgit>git checkout master
D       file2.txt
Switched to branch 'master'
D:\testgit>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    file2.txt
#

So, our changes are not correlated with a branch until we commit them! Let’s commit them to the master repository and confirm that:

D:\testgit>git commit -m "Deleted file2.txt"
[master 6f8749d] Deleted file2.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 file2.txt
D:\testgit>git status
# On branch master
nothing to commit, working directory clean
D:\testgit>dir file2.txt
[...]
File not found
D:\testgit>git checkout slave
Switched to branch 'slave'
D:\testgit>git status
# On branch slave
nothing to commit, working directory clean
D:\testgit>dir file2.txt
[...]
08/10/2013  05:59 pm                15 file2.txt

This is interesting… Let’s try modifying the file2.txt (which does not exist to the master branch):

D:\testgit>git branch
  master
* slave
D:\testgit>echo new file2 contents > file2.txt
D:\testgit>git add .
D:\testgit>git status
# On branch slave
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   file2.txt
#
D:\testgit>git checkout master
error: Your local changes to the following files would be overwritten by checkout:
       file2.txt
Please, commit your changes or stash them before you can switch branches.
Aborting

We won’t be able to change the current branch until we commit the conflicting change:

D:\testgit>git commit -m "Modified file2"
[slave b5af832] Modified file2
 1 file changed, 1 insertion(+), 1 deletion(-)
D:\testgit>git checkout master
Switched to branch 'master'

Remote branches

For each local repository you can define a number of remote repositories, or remotes as git calls them. When you clone a repository from github.com, your local repository will have one remote, named origin. We will try to add the same remote by hand. Let’s suppose that we have created a repository in github.com named testgit. After that we wil issue:

D:\testgit>git remote
D:\testgit>git remote add origin https://github.com/spapas/testgit.git
D:\testgit>git remote
origin

So no we have one remote named origin that is linked with https://github.com/spapas/testgit.git. Let’s try to push our master branch to the origin remote:

D:\testgit>git push origin master
Username for 'https://github.com': spapas
Password for 'https://spapas@github.com':
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 531 bytes, done.
Total 7 (delta 1), reused 0 (delta 0)
To https://github.com/spapas/testgit.git
 * [new branch]      master -> master
D:\testgit>git branch -r
  master
* slave
  remote/origin/master

We see now that we have three branches. Two local (master slave) and one remote (origin/master). We will also add the slave remote (origin/slave):

D:\testgit>git branch -r
  origin/master
  origin/slave

Let’s do a change to our local repository and then push them to the remote:

D:\testgit>notepad file3.txt
D:\testgit>git add .
D:\testgit>git status
# On branch slave
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   file3.txt
#
D:\testgit>git commit -m "Changed file3.txt"
[slave ce3b7b9] Changed file3.txt
 1 file changed, 1 insertion(+), 1 deletion(-)
D:\testgit>git push origin slave
Username for 'https://github.com': spapas
Password for 'https://spapas@github.com':
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 299 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/spapas/testgit.git
   b5af832..ce3b7b9  slave -> slave

Everything works as expected. The final thing to test is to try checking out a remote branch:

D:\testgit>git checkout master
Switched to branch 'master'
D:\testgit>echo new new file1 > file1.txt
D:\testgit>more file1.txt
 new new file1
D:\testgit>git checkout origin/master
M       file1.txt
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 6f8749d... Deleted file2.txt
D:\testgit>git status
# Not currently on any branch.
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   file1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
D:\testgit>more file1.txt
new new file1

So, it seems that when we check out the remote branch, we won’t have any local branches, however the change we did to the file1.txt is transfered just like when switching from one local repository to another. We can then add the changes and commit:

D:\testgit>git add .
D:\testgit>git commit
[detached HEAD 506674c] foo
 1 file changed, 1 insertion(+), 1 deletion(-)
 D:\testgit>git status
# Not currently on any branch.
nothing to commit, working directory clean
D:\testgit>git branch
* (no branch)
  master
  slave

So we are working with an unnamed branch! We have to name it to be able to work without problems:

D:\testgit>git checkout -b named_branch
Switched to a new branch 'named_branch'
D:\testgit>git branch
  master
* named_branch
  slave

Finally we may push again the named_branch to our remote origin.