Difference between revisions of "Talk:Dotfiles"

From ArchWiki
Jump to: navigation, search
(Category: rm closed discussion)
(Shell frameworks: re)
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Comment ==
+
== Shell frameworks ==
This page is apparently alphabetical :P --[[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 4:26pm, 18 May 2012
+
  
== Formatting ==
+
Currently there is no easy way to know if a shell configuration in [[dotfiles#Repositories]] uses a ''framework'' without checking each repository. I think it would be better if used frameworks were listed in brackets next to shell name. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:37, 22 November 2016 (UTC)
  
I undid revision 202148 by Earnest, in my opinion it looks much neater to have things layed out in a table, as opposed to a list format. It's more compact as well. --wolfcore
+
:Since no one objected, I changed "Shell" to "Shell (shell framework)". Let's see if people start listing them. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:16, 30 December 2016 (UTC)
:This is still up for review, there is a real danger of things becoming rather bloated. Anyone else who sees this, look over the specific revision and leave a comment on which you'd prefer. Version1, Version2 or the Table layout. -- [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 19:50, 20 May 2012 (UTC)
+
::My opinion is that the table layout is the best solution as it forces a consistent layout for all users; using a list would make users add notes and other stuff that would better fit their user page. This is also why I'd also recommend to add possible notes in each user's page instead of the "Repo Specific Notes" section, which should be used only for users not registered in the ArchWiki. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:09, 21 May 2012 (UTC)
+
  
<s>Added category and summary section</s>. At the moment this is all mock-up and scaffolding, feel free to change in any regard or discuss any potential 'bloat' or redundancy. -- [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 18:50, 19 May 2012 (UTC)
+
== Bare repository and alias method ==
:Summary section has no real place. Last task at hand might be to include more categories within the table. -- [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 18:08, 22 May 2012 (UTC)
+
 
::Too many catagories, this really needs to be a list the grid just doesn't look good at all -- [[User:Danielwallace|Danielwallace]] ([[User talk:Danielwallace|talk]]) 18:42, 22 May 2012 (UTC)
+
Hi all, I'd love to expand this out to include the method coved in [https://news.ycombinator.com/item?id=11070797 this HN discussion]. The simplicity of it is rather beautiful and it keeps the tracking isolated from the rest of $HOME.
 +
Before I do that, I'm new here so don't want to just start making sizeable edits with some form of discussion. Can anyone see any advantages of the currently listed gitignore method that this does not provide? -- [[User:Kimburgess|Kimburgess]] ([[User talk:Kimburgess|talk]])
 +
 
 +
:So basically all it does is hide the untracked files in the commit window? IOW, a half-baked variant of [[Dotfiles#Using_gitignore]] which actually ignores the files instead of hiding them. One example where this is better if you end up running {{ic|git clean}}. If the files are not ignored, they'd end up deleted. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 26 December 2016 (UTC)
 +
 
 +
:Almost. Although it's hiding rather than excluding, there's one important difference — the actual repo is in a sub directory, not the base of $HOME. This means when you're sitting in the $HOME tree, attempting to run any vanilla git commands will fail (as it's not a repo). This protects you a little, but also stops any git cruft from showing for users running with git aware prompt strings (i.e. showing current branch / state). You could add a wildcard exclusion to this method as well, but it would come with the tradeoff of losing visibility of what you don't have tracked in your dotfiles.--[[User:Kimburgess|Kimburgess]] ([[User talk:Kimburgess|talk]]) 23:52, 26 December 2016 (UTC)

Latest revision as of 13:16, 30 December 2016

Shell frameworks

Currently there is no easy way to know if a shell configuration in dotfiles#Repositories uses a framework without checking each repository. I think it would be better if used frameworks were listed in brackets next to shell name. -- nl6720 (talk) 13:37, 22 November 2016 (UTC)

Since no one objected, I changed "Shell" to "Shell (shell framework)". Let's see if people start listing them. -- nl6720 (talk) 13:16, 30 December 2016 (UTC)

Bare repository and alias method

Hi all, I'd love to expand this out to include the method coved in this HN discussion. The simplicity of it is rather beautiful and it keeps the tracking isolated from the rest of $HOME. Before I do that, I'm new here so don't want to just start making sizeable edits with some form of discussion. Can anyone see any advantages of the currently listed gitignore method that this does not provide? -- Kimburgess (talk)

So basically all it does is hide the untracked files in the commit window? IOW, a half-baked variant of Dotfiles#Using_gitignore which actually ignores the files instead of hiding them. One example where this is better if you end up running git clean. If the files are not ignored, they'd end up deleted. -- Alad (talk) 12:51, 26 December 2016 (UTC)
Almost. Although it's hiding rather than excluding, there's one important difference — the actual repo is in a sub directory, not the base of $HOME. This means when you're sitting in the $HOME tree, attempting to run any vanilla git commands will fail (as it's not a repo). This protects you a little, but also stops any git cruft from showing for users running with git aware prompt strings (i.e. showing current branch / state). You could add a wildcard exclusion to this method as well, but it would come with the tradeoff of losing visibility of what you don't have tracked in your dotfiles.--Kimburgess (talk) 23:52, 26 December 2016 (UTC)