Re: [hackers] [sbase] [PATCH] Add .gitignore
On 2019-06-17, Quentin Rameau wrote: >> On 2019-06-17, Quentin Rameau wrote: >> >> How do you deal with ~250 lines of "Untracked files:" in the `git >> >> status` output? Can you answer this question? I'm curious why this doesn't obstruct your workflow. >> >> If you want to see them, you can always run `git status --ignored`. >> > >> > If you want it, you can always run `make .gitignore` *once*. >> >> Once for every clone of sbase. > > Yes, as opposed to once for every git status command issued. Perhaps you can set up a shorter git alias for `status --ignored`. This will also work for other repositories that contain a .gitignore. >> >> > What's the rationale for having it duplicated both in the SCM and in >> >> > the >> >> > Makefile then? >> >> >> >> So that if a utility is added or removed, .gitignore can easily be kept >> >> in >> >> sync. >> > >> > So what's the point of having .gitignore tracked by the SCM? >> >> So that it gets applied by default. > > It seems you're deliberately not answering the question, or are > suggesting bloating the make/SCM system with a justification for > lazyness. I answered the question. I want .gitignore checked in because then the configuration gets applied by default. I want a rule to update it so that it is easy to keep in sync with the Makefile. > You asked if there was any objection to this, you got some, now do what > you want. I'm trying to understand your objection and workflow. My current understanding is that you think it bloats the repository, and you prefer to see the 250 lines of build artifacts when you run `git status`. Is that an accurate summary? In my opinion, since the file is only 700 bytes long, I think its usefulness outweighs its bloat. I'll wait a few more days in case someone else has an opinion. > But pushing it both into the Makefile and the SCM is not justified at > all, chose either one. The Makefile rule will help to prevent it from getting out of date with respect to the Makefile, so I think it is justified. It won't get run unless you explicitly build it.
Re: [hackers] [sbase] [PATCH] Add .gitignore
> On 2019-06-17, Quentin Rameau wrote: > >> How do you deal with ~250 lines of "Untracked files:" in the `git > >> status` output? > >> > >> If you want to see them, you can always run `git status --ignored`. > > > > If you want it, you can always run `make .gitignore` *once*. > > Once for every clone of sbase. Yes, as opposed to once for every git status command issued. > >> >> The place for user-specific and repository-specific ignored files is > >> >> .git/info/exclude. But in general, we don't know the location of the > >> >> .git directory, so we'd probably have to use some git command to > >> >> figure out exactly where to put it. > >> > > >> > There's no “we”, that's the user's responsability to figure out where > >> > to put it. > >> > >> There is a "we" if a Makefile rule were to be added, since it needs to > >> create the file at the appropriate location. > > > > The appropriate location is .gitignore. > > No, see gitignore(5): > > * Patterns which should be version-controlled and distributed to other > repositories via clone (i.e., files that all developers will want to > ignore) should go into a .gitignore file. > > * Patterns which are specific to a particular repository but which do > not need to be shared with other related repositories (e.g., auxiliary > files that live inside the repository but are specific to one user’s > workflow) should go into the $GIT_DIR/info/exclude file. > > * Patterns which a user wants Git to ignore in all situations (e.g., > backup or temporary files generated by the user’s editor of choice) > generally go into a file specified by core.excludesFile in the user’s > ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If > $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore > is used instead. > > >> > What's the rationale for having it duplicated both in the SCM and in > >> > the > >> > Makefile then? > >> > >> So that if a utility is added or removed, .gitignore can easily be kept in > >> sync. > > > > So what's the point of having .gitignore tracked by the SCM? > > So that it gets applied by default. It seems you're deliberately not answering the question, or are suggesting bloating the make/SCM system with a justification for lazyness. You asked if there was any objection to this, you got some, now do what you want. But pushing it both into the Makefile and the SCM is not justified at all, chose either one.
Re: [hackers] [sbase] [PATCH] Add .gitignore
On 2019-06-17, Quentin Rameau wrote: >> How do you deal with ~250 lines of "Untracked files:" in the `git >> status` output? >> >> If you want to see them, you can always run `git status --ignored`. > > If you want it, you can always run `make .gitignore` *once*. Once for every clone of sbase. >> >> The place for user-specific and repository-specific ignored files is >> >> .git/info/exclude. But in general, we don't know the location of the >> >> .git directory, so we'd probably have to use some git command to >> >> figure out exactly where to put it. >> > >> > There's no “we”, that's the user's responsability to figure out where >> > to put it. >> >> There is a "we" if a Makefile rule were to be added, since it needs to >> create the file at the appropriate location. > > The appropriate location is .gitignore. No, see gitignore(5): * Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file. * Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file. * Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead. >> > What's the rationale for having it duplicated both in the SCM and in >> > the >> > Makefile then? >> >> So that if a utility is added or removed, .gitignore can easily be kept in >> sync. > > So what's the point of having .gitignore tracked by the SCM? So that it gets applied by default.
Re: [hackers] [sbase] [PATCH] Add .gitignore
On Mon, 17 Jun 2019 13:40:47 -0700 Michael Forney wrote: > On 2019-06-17, Quentin Rameau wrote: > >> What's the downside to having it checked into the repository? Are > >> there any reasons why a user wouldn't want this feature? Personally, I > >> want it in every clone of sbase I make, and I imagine most other > >> people want this as well. It is annoying to have `git status` scroll > >> my changes off the screen due to all the build artifacts. > > > > Well, personnaly I don't want it, I prefer to have a clear view of the > > clone status, hence the “user-side feature”, as in user-specific > > preference. > > How do you deal with ~250 lines of "Untracked files:" in the `git > status` output? > > If you want to see them, you can always run `git status --ignored`. If you want it, you can always run `make .gitignore` *once*. > >> The place for user-specific and repository-specific ignored files is > >> .git/info/exclude. But in general, we don't know the location of the > >> .git directory, so we'd probably have to use some git command to > >> figure out exactly where to put it. > > > > There's no “we”, that's the user's responsability to figure out where > > to put it. > > There is a "we" if a Makefile rule were to be added, since it needs to > create the file at the appropriate location. The appropriate location is .gitignore. > > > What's the rationale for having it duplicated both in the SCM and in the > > Makefile then? > > So that if a utility is added or removed, .gitignore can easily be kept in > sync. So what's the point of having .gitignore tracked by the SCM?
Re: [hackers] [sbase] [PATCH] Add .gitignore
On 2019-06-17, Quentin Rameau wrote: >> What's the downside to having it checked into the repository? Are >> there any reasons why a user wouldn't want this feature? Personally, I >> want it in every clone of sbase I make, and I imagine most other >> people want this as well. It is annoying to have `git status` scroll >> my changes off the screen due to all the build artifacts. > > Well, personnaly I don't want it, I prefer to have a clear view of the > clone status, hence the “user-side feature”, as in user-specific > preference. How do you deal with ~250 lines of "Untracked files:" in the `git status` output? If you want to see them, you can always run `git status --ignored`. >> The place for user-specific and repository-specific ignored files is >> .git/info/exclude. But in general, we don't know the location of the >> .git directory, so we'd probably have to use some git command to >> figure out exactly where to put it. > > There's no “we”, that's the user's responsability to figure out where > to put it. There is a "we" if a Makefile rule were to be added, since it needs to create the file at the appropriate location. > What's the rationale for having it duplicated both in the SCM and in the > Makefile then? So that if a utility is added or removed, .gitignore can easily be kept in sync.
Re: [hackers] [sbase] [PATCH] Add .gitignore
> > I'm not really keen on pushing this file to the source history, I think > > this should be kept separate, this is a user-side feature. > > What's the downside to having it checked into the repository? Are > there any reasons why a user wouldn't want this feature? Personally, I > want it in every clone of sbase I make, and I imagine most other > people want this as well. It is annoying to have `git status` scroll > my changes off the screen due to all the build artifacts. Well, personnaly I don't want it, I prefer to have a clear view of the clone status, hence the “user-side feature”, as in user-specific preference. > > But having a rule un the Makefile, as you did, is a good compromise > > there, if the user wants it, he can have it with little additionnal > > effort. > > > > So I'd be for pushing the Makefile rule, not committing the actual file > > into the development history > > The place for user-specific and repository-specific ignored files is > .git/info/exclude. But in general, we don't know the location of the > .git directory, so we'd probably have to use some git command to > figure out exactly where to put it. There's no “we”, that's the user's responsability to figure out where to put it. What's the rationale for having it duplicated both in the SCM and in the Makefile then?
Re: [hackers] [sbase] [PATCH] Add .gitignore
On 2019-06-13, Quentin Rameau wrote: > Hello Michael, > >> Also, add rule to regenerate in case executable list changes. >> --- >> Any objection to this? > > I'm not really keen on pushing this file to the source history, I think > this should be kept separate, this is a user-side feature. What's the downside to having it checked into the repository? Are there any reasons why a user wouldn't want this feature? Personally, I want it in every clone of sbase I make, and I imagine most other people want this as well. It is annoying to have `git status` scroll my changes off the screen due to all the build artifacts. > But having a rule un the Makefile, as you did, is a good compromise > there, if the user wants it, he can have it with little additionnal > effort. > > So I'd be for pushing the Makefile rule, not committing the actual file > into the development history The place for user-specific and repository-specific ignored files is .git/info/exclude. But in general, we don't know the location of the .git directory, so we'd probably have to use some git command to figure out exactly where to put it.
Re: [hackers] [sbase] [PATCH] Add .gitignore
Hello Michael, > Also, add rule to regenerate in case executable list changes. > --- > Any objection to this? I'm not really keen on pushing this file to the source history, I think this should be kept separate, this is a user-side feature. But having a rule un the Makefile, as you did, is a good compromise there, if the user wants it, he can have it with little additionnal effort. So I'd be for pushing the Makefile rule, not committing the actual file into the development history
[hackers] [sbase] [PATCH] Add .gitignore
Also, add rule to regenerate in case executable list changes.
---
Any objection to this?
.gitignore | 99 ++
Makefile | 5 ++-
2 files changed, 103 insertions(+), 1 deletion(-)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..f4709cb
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,99 @@
+*.o
+/getconf.h
+/libutf.a
+/libutil.a
+/basename
+/cal
+/cat
+/chgrp
+/chmod
+/chown
+/chroot
+/cksum
+/cmp
+/cols
+/comm
+/cp
+/cron
+/cut
+/date
+/dirname
+/du
+/echo
+/ed
+/env
+/expand
+/expr
+/false
+/find
+/flock
+/fold
+/getconf
+/grep
+/head
+/hostname
+/join
+/kill
+/link
+/ln
+/logger
+/logname
+/ls
+/md5sum
+/mkdir
+/mkfifo
+/mktemp
+/mv
+/nice
+/nl
+/nohup
+/od
+/paste
+/pathchk
+/printenv
+/printf
+/pwd
+/readlink
+/renice
+/rev
+/rm
+/rmdir
+/sed
+/seq
+/setsid
+/sha1sum
+/sha224sum
+/sha256sum
+/sha384sum
+/sha512sum
+/sha512-224sum
+/sha512-256sum
+/sleep
+/sort
+/split
+/sponge
+/strings
+/sync
+/tail
+/tar
+/tee
+/test
+/tftp
+/time
+/touch
+/tr
+/true
+/tsort
+/tty
+/uname
+/unexpand
+/uniq
+/unlink
+/uudecode
+/uuencode
+/wc
+/which
+/whoami
+/xargs
+/xinstall
+/yes
diff --git a/Makefile b/Makefile
index 0e421e7..75b1618 100644
--- a/Makefile
+++ b/Makefile
@@ -274,4 +274,7 @@ clean:
rm -f $(BIN) $(OBJ) $(LIB) sbase-box sbase-$(VERSION).tar.gz
rm -f getconf.h
-.PHONY: all install uninstall dist sbase-box sbase-box-install
sbase-box-uninstall clean
+.gitignore:
+ { printf '*.o\n' ; printf '/%s\n' getconf.h $(LIB) $(BIN) ; } > $@
+
+.PHONY: all install uninstall dist sbase-box sbase-box-install
sbase-box-uninstall clean .gitignore
--
2.20.1
