Forum Programmation.autre Git : comment merger une arborescence de fichiers ? (pas leur contenu)

Posté par . Licence CC by-sa
1
23
jan.
2017

Git : comment merger une arborescence de fichiers ? (pas leur contenu).

Bonjour

Je voudrais merger une raborescence de fichier sous git, pas leur contenu, mais juste 2 arborescences.

J'ai cloné la branche de mon collègue : BrancheA

BrancheA

RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v01

Lui travaille de son côté et obtient après commit de ses modifs sur la BrancheA

BrancheA

RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v02 (new)
|--Collègue_Fichier3.v01 (new)

Moi de mon côté je travaille et ajoute des fichiers sans modifier les siens.

BrancheA (git clonée)

(...)

Forum Linux.redhat Trouver source d'un log

Posté par . Licence CC by-sa
0
28
oct.
2015

Bonjour,

Je viens de commencer dans une très grande entreprise française connu.
Ils ont développé leur propre outil de monitoring (type Nagios).
Cependant plusieurs personnes se sont relayés sur ce développement, et l'organisation logique de certain script est devenu assez aléatoire …
Existe t-il une solution simple pour savoir quel script a généré mon log ?

je fais d'énorme find /data -name "*" -exec grep -Hn "nomdefichier" {} \;

en espérant trouver le fichier qui possède la ligne "> nomdefichier" dans (...)

Forum Programmation.python Quelle arborescence pour un projet Python Qt ?

Posté par . Licence CC by-sa
1
30
mar.
2015

Bonjour.

Je travaille sur une application PyQt (python + Qt) et je me demande comment organiser mon arborescence de fichiers. J'ai essayé de m'inspirer de projets libres, mais je n'ai pas trouvé la solution ultime. J'ai l'impression que chacun fait un peu à sa sauce.

Pour l'instant, je fais ceci:

mon_logiciel/
    .git/
    src/
        mon_logiciel.py
        mon_logiciel/
            mainwindow.py
            congif.py
            status_bar.py
            data.py
            mplwidget.py
            ...
            datareader/
                ...
            dataplotter/
                ...
        resources/
            ui/
                mainwindow.ui
                datareader/
                    ...
                dataplotter/
                    ...
            images/
        i18n/
            ts/
                mon_logiciel_fr.ts
    tests/
    doc/
    examples/
    tools/
(...)

Forum Programmation.shell Copier tous les fichiers d'une arborescence dans un même répertoire

Posté par .
2
5
juil.
2012

Salut,

J'ai un tas de fichiers texte dans une arborescence, et je voudrais les copier
tous dans un même répertoire de destination, comme ceci:

content/foo.txt           ->      $DEST/foo.txt
content/bar.md            ->      $DEST/bar.md
content/baz/quux.html     ->      $DEST/quux.html
content/baz/foobar.rst    ->      $DEST/foobar.rst
... etc ...

J'ai essayé de faire comme ceci:

find content/ -exec cp -v {} $DEST/`basename {}` ';'

Mais bien entendu, ça n'a pas marché, puisque c'est le shell qui interprétait la
commande basename et pas find

J'ai aussi regardé dans le man (...)

/run or not /run

52
4
avr.
2011
Linux

Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.

Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.

Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.

À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.

Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.

Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.

Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.

Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.

Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !

NdM : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.