dic
13

git bash prompt in Fedora 18

 

If you are a git user, chances are your are using a customized bash prompt,
which is usually defined in ~/.bashrc like this:

PS1= [u@h W$(__git_ps1 " (%s)")]$

In case you don t know it, the __git_ps1 is a handy function provided by the git package to show relevant git repository information (branch name, merge status, etc) right at the prompt.

For instance, this is what the prompt looks like when I cd into a git checkout:

[giallu@qbert gittest (master)]$

Today, after updating one of my development boxes to (the not yet released, but we re getting there…) Fedora 18, I started seeing this error in all my terminals:

bash: __git_ps1: command not found
[giallu@qbert ~]$

I found that the problem is caused by the move of the __git_ps1 function, from /etc/bash_completion.d/git to /usr/share/git-core/contrib/completion/git-prompt.sh

So, in order to fix the issue, you just need to edit your bashrc like this:

. /usr/share/git-core/contrib/completion/git-prompt.sh
PS1= [u@h W$(__git_ps1 " (%s)")]$

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

gen
14

Sincronizzazione e Deploy di un progetto web su un server proprio via ssh e git hooks

 

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

ott
31

Linuxcast #28 – Gedit il Text Editor / IDE per Linux

 

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

giu
25

Riparare git ovvero “fatal: object XXX is corrupted”

 

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

mar
30

Gli “orfani” di Delicious possono archiviare i bookmark con Gitmarks

 

GitHub OctocatGitmarks è un sistema per il salvataggio dei preferiti creato da Hilary Mason su GitHub: scritto in Python, funziona dal terminale ed è basato su Git. Una soluzione interessante per chi volesse sostituire Delicious, dal quale può importare i bookmark, prima che possa essere troppo tardi. Gitmarks è sia open source sia free software.

Basato sul concetto di P2P, Gitmarks può essere avviato direttamente su GitHub (sul quale aggiunge delle funzionalità sociali) oppure sul proprio server. La lista dei comandi è essenziale: ai preferiti si possono associare, oltre al titolo, una serie di etichette. L’archivio dei link salvati può essere interrogato utilizzando GREP.

Oltre alla riga di comando, Gitmarks è dotato di un comodo bookmarklet per il browser. A dispetto dell’estrema semplicità del codice, Gitmarks è un progetto convincente: la formula di rilascio sotto GPLv3 su GitHub lo rende particolarmente duttile, è già stata inviata una richiesta per migliorare il tagging degli indirizzi salvati.

Via | ReadWriteWeb

Gli “orfani” di Delicious possono archiviare i bookmark con Gitmarks é stato pubblicato su ossblog alle 09:00 di mercoledì 30 marzo 2011.

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

mar
24

Integrare Nautilus con Git

 

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

gen
21

start tracking existing branches with git

 

Git has the concept of “tracking branches“: a local branch can be linked to a remote branch so pull and push commands have a default destination on the remote repository.

As an added benefit, you will get an informative message on top of “git status” output telling you which one of the two ends has new commits, like this:

$ git status
# On branch master
# Your branch is behind  origin/master  by 11 commits, and can be fast-forwarded

Now, this works by default with the master branch but if you created a local branch like:

$ git checkout -b new_branch
Switched to a new branch  new_branch 

then decided to push it to origin (or any other remote), tracking will not be active unless you use the command:

$ git push --set-upstream origin new_branch
Counting objects: 40, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (25/25), 3.25 KiB, done.
Total 25 (delta 19), reused 0 (delta 0)
To git@github.com:giallu/testrepo.git
   dcdb736..643a3f2  new_branch -> new_branch
Branch new_branch set up to track remote branch new_branch from origin

If you forget to use the –set-upstream option during push you can also do it later (from version 1.7) with:

$ git --set-upstream origin new_branch


Popularity: unranked [?]



Puoi visualizzare il post originale qui.

ott
09

Git4LaTeX: una guida introduttiva a Git per progetti LaTeX

 

Chi scrive documenti con LaTeX potrebbe a un certo punto avere il bisogno di controllare lo sviluppo dei vari documenti, in modo da controllare i cambiamenti effettuati tra un salvataggio e l altro per poter, eventualmente, anche individuare quando sono stati introdotti degli errori e poter in pochi passi ripristinare una versione precedente. In vostro soccorso arriva allora Git, programma di controllo versione. L uso tipico di Git è quello di tenere traccia dello sviluppo di un software, ma svolge ugualmente bene il suo lavoro con i documenti LaTeX.

Proprio per spiegare come utilizzare insieme Git e LaTeX, sul forum del Guit l utente dianoia ha annunciato la realizzazione di una guida (con licenza CC-BY-NC-SA 2.5 Italy) sull uso di Git per gestire lo sviluppo di un documento scritto in LaTeX. La guida non si prefigge grandi scopi, non diventerete degli esperti di Git leggendola, ma è sicuramente d aiuto per riuscire a usare insieme questi due utili strumenti.

Trovate il codice sorgente della sua guida di dianoia su Gitorious all indirizzo http://www.gitorious.org/git4latex e potete scaricare il documento PDF (che potrebbe risultare non aggiornato) all indirizzo http://hotfile.com/dl/74484041/9c21bb8/git4latex.pdf.html. Se avete Git sul vostro sistema potete potete clonare il repository con il comando

git clone git://gitorious.org/git4latex/git4latex.git

Infine il codice sorgente può essere scaricato anche in un archivio compresso all indirizzo http://www.gitorious.org/git4latex/git4latex/archive-tarball/master.

Visto che l utente ha saggiamente pensato di utilizzare una licenza libera per questa utile guida ho realizzato un fork che potete trovare sempre su Gitourious all indirizzo http://www.gitorious.org/~elrondgit/git4latex/elrondgits-git4latex/commits/elrond, il PDF (anche questo non sempre aggiornato) può essere scaricato all indirizzo http://elubuntu.altervista.org/LaTeX/git4latex.pdf. Sempre se avete Git installato nel sistema potete clonare il repository con il comando

git clone git://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex.git elrondgits-git4latex
cd elrondgits-git4latex # per entrare nella cartella
git checkout elrond # per aprire il branch

(gli ultimi due comandi, come spiegato nei commenti, servono per visualizzare il mio branch). Per finire anche questo lungo elenco di indirizzi segnalo che il mio branch può essere scaricato in un archivio compresso all indirizzo http://www.gitorious.org/git4latex/elrondgits-git4latex/archive-tarball/elrond.

Happy TeXing :)

Popularity: unranked [?]



Puoi visualizzare il post originale qui.

lug
28

GitHub raggiunte il milione di repository

 

Gli sviluppatori di GitHub hanno annunciato che il loro servizio è arrivato al milionesimo repository.

Secondo Scott Chacon, vice presidente della sezione Research & Development, circa il 60% dei repository sono progetti interi, mentre il restante 40% sono soltanto code snippet. Lanciato poco più di due anni fa GitHub si è ormai imposto come la soluzione di hosting per i progetti open source che utilizzano Git.

Se i progetti open source non devono pagare, le aziende che vogliono mantenere il loro repository privato hanno bisogno di accedere alla versione premium.

Via | GitHub

GitHub raggiunte il milione di repository é stato pubblicato su ossblog alle 10:00 di mercoledì 28 luglio 2010.

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

apr
25

Gitolite

 

Gitolite è un gatekeeper basato su ssh per la gestione di repository ssh.

Il progetto consente di utilizzare una normale chiave ssh per l’accesso autenticato ai repository Git e permette agli amministratori del sistema di decidere in maniera precisa chi può accedere a quali rami e con quali permessi.

Il progetto si presenta come molto utile sia in ambito lavorativo sia per chi non ha la possibilità di creare utenti aggiuntivi per ogni sviluppatore che partecipa al progetto. È scritto in perl e rilasciato sotto licenza GPLv2.

Via | Gitolite

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

apr
10

Un terminale più funzionale con un .bashrc stiloso

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

feb
06

Giggle, frontend GTK+ per Git

 

Giggle è un frontend scritto in Gtk+ per Git.

Il programma è stato sviluppato inizialmente durante un Hackathon tre anni fa e da allora ha conosciuto un periodo senza sviluppo, ma ora si sta progredendo verso la versione 0.5

Recentemente è stata rilasciata la versione 0.4.95 ed il software è disponibile già pacchettizzato per Debian, Fedora, OpenSuse ed Ubuntu.

Via | Giggle

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

dic
16

Come viene gestito il kernel Linux

 

Due settimane fa abbiamo presentato l’intervista a Greg Kroah-Hartman, uno degli sviluppatori principali che lavorano sul kernel Linux.

Con il passare del tempo il lavoro dei programmatori principali è diventato quello di gestire le patch che arrivano da più parti e dirigere i lavori. In questo video si vede nel dettaglio come funziona l’inclusione di una nuova patch e, nel finale senza commenti, come il procedimento possa essere veloce.

Il tutto utilizzando i classici strumenti da terminale come patch, quilt, git, mutt, vim ed altri che a volte qualcuno tende a denigrare marchiandoli semplicemente come “old school”.

Via | Kroah

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

nov
18

Come Google manipola il kernle Linux, alcuni numeri

 

Post originale su Linux e dintorni

Una delle aziende più potenti del web basa la propria forza su GNU/Linux, ecco alcuni dettagli sul suo utilizzo

Si può tranquillamente affermare con relativa certezza che al mondo non esiste azienda con il maggior numero di installazione GNU/Linux attive rispetto a Google.

Rispetto al suo enorme utilizzo all’interno dell’azienda poco o nulla si sa sui sistemi che Google implementa nelle sue macchine per adattare il nostro OS preferito alle sue esigenze, Mike Waychison, dipendente dell’azienda, cerca di far luce sui problemi e le soluzioni che a Mountain View incontrano sul loro cammino.

Al di la di quello che si possa pensare all’interno di Google il codice kernel viene gestito con un tool che ha ben poco di open ovvero Perforce, magari potrebbero rivolgersi a soluzioni aperte sicuramente più performanti.

Non esistono diversi rami del kernel Linux al quale i tecnici lavorano ma tutte le forse vengono impegnate nell’uni filone principale di codice; 30 sono gli ingegneri che ogni giorno lavorano a tempo pieno al kernel Linux.

Hanno iniziato con il kernel 2.4.18 al quale sono state applicate patch per un ammontare enorme, circa 2000 modifiche; successivamente, dopo aver aggiunto ben 492.000 linee di codice, la scelta di passare al 2.6.11 per via della necessità di avere del supporto SATA.

Alla versione 2.6.11 è seguita la 2.6.18 ed attualmente si sta lavorando sulla preparazione di un kernel base 2.6.26.

Se desiderate qualche numero per questa nuova versione in preparazione eccovi accontentati:

  • 1208 patch
  • 300.000 linee di codice aggiuntive
  • 25% di patch corrisponde a backport di nuove funzionalità

Fortunatamente ci sono dei piani di sviluppo secondo i quali tutto questo lavoro non ha come obbiettivo quello di rimanere confinato all’interno degli uffici del colosso ma si sta cercando di collaborare con i tecnici che tutti i giorni creano il kernel.

Un primo passo è la volontà di passare a GIT per la gestione del codice creando simultaneamente tanti rami quanti sono gli ingegneri che lavorano sul codice stesso, ogni tre mesi i cambiamenti verranno valutati e rapportati alla linea di sviluppo principale.

L’attuale sistema di gestione è di difficile coordinazione con il resto dello sviluppo kernel che viene effettuato fuori dalle mura del GooglePlex, uno dei maggiori problemi è proprio l’allineamento di versione, visto che Google non riesce a mantenere il frenetico ritmo di sviluppo della comunità kernel si trova nella spiacevole condizione di sviluppare patch essenziali per l’azienda che però vanno totalmente riscritte o modificate se si cerca di passare ad un kernel più recente.

Questa rincorsa fa accumulare sempre più ritardo nello sviluppo come in loop che si ripete in continuazione, ad ogni kernel altro sviluppo altre modifiche ed altro tempo che inevitabilmente fa slittare la programmazione del kernel che è uscito nel frattempo.

Questo è il vero male che Google tenta di sconfiggere adottando nuove politiche di gestione del lavoro.

Il lavoro del colosso web è orientato soprattutto all’efficienza in termini di velocità di esecuzione delle richieste, requisito essenziale per l’azienda, successivamente i tecnici si scontrano spesso con le latenze ovvero il tallone di Achille per i sistemi server.

Maggiore collaborazione tra il gruppo di sviluppatori interno e la comunità sarebbe auspicabile fin da subito, sarebbe un modo per scambiare reciproche conoscenze le quali potrebbero migliorare rapidamente il prodotto rendendolo migliore di quanto non lo sia ora.

Speriamo in un futuro di collaborazione e di grandi successi d’altronde se Google è quello che è oggi lo deve in larga parte alla comunità Open…..don’t be evil.

Ciao a tutti.

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

ott
14

What to do with a Github pull request

 

So, I ve got a pull request for the supybot-mantis plugin I m hosting at github.com; how do I move the commits from the fork back into the master repo?

Searching the net does not give many results, but from some of them I ve got the general idea: I just need to add a new remote to track changes in the fork, then merge in the changes so the whole thing was just few commands away :)

Initial situation
git branch -a
* master
origin/HEAD
origin/master

Add new remote and fetch data
git remote add -f hugues git://github.com/hugues/

New situation
git branch -a
* master
hugues/master
origin/HEAD
origin/master

(Optionally) review commits in the new remote with:
[giallu@bingo supybot-mantis]$ git log -p ..hugues/master

Everything ok, merge from the forked repo
git merge hugues/master

Finally push to github
git push

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

top