Re: [git-users] [ANNOUNCE] git-fc 0.1: new fork of git for users
On Wed, May 24, 2023 at 5:34 AM Konstantin Khomoutov wrote: > On Tue, May 23, 2023 at 04:21:30PM -0500, Felipe Contreras wrote: > > [...] > > > For completeness, there's the link to a message which can be served as an > > > entry point to a different view on these matters which is also present in > > > the > > > Git developers' community [7]. > > > > > > I should note that I do not have a strong opinion on this situation (or at > > > least I do not have an opinion I'd like to share) - merely trying to make > > > it > > > possible to be able to see a more complete picture for those who finds it > > > interesting. > > > > > > 7. > > > https://lore.kernel.org/git/20230511012558.ga1464...@coredump.intra.peff.net/ > > > > Needless to say these are Jeff King's *opinions*, these are not facts. > [...] > > Sadly they can't focus on the technical discussion. > [...] > > I should have probably explicitly stated in my mail that I do not expect any > responses to it. My response was not necessarily to you, but for the record. You responded to paint a "more complete picture for those who finds it interesting", well, I did the same thing: for those who find that whole situation interesting, I provided context that I think is important. > My view of the situation is mostly as follows: you post an > announcement mail which prominently states that such and such > high-profile Git developers are wrong, and you're right I did not do that. I provided objective claims that can be verified. When I say Junio is the *only* git developer against the term "staging area", that's not an "opinion", that's a fact. It can be verified, and I provided all the receipts in my blog post, for those who actually want to verify it. When I say the Git PLC did not allow me to defend myself, that's also a fact, not an opinion. I was very conscious of not stating opinions in my announcement. I did not even claim that the Git PLC or even Junio were wrong. > I merely wanted to make the opinions of "the other side" to be more visible - > simply because you have made your announcement on a mailing list which remains > blissfully unaware of those wars fought. I have explicitly stated that I do > not want to take any side in these issues - merely make both positions sort of > equally presented to those who might be interested to learn more. I did not expect you to take any side or even respond. My intention was to provide context that in my opinion is important. And yes, I attached a few opinions in my response to you, which I feel I'm entitled to have. But ultimately it's up to people to judge by themselves if they want to read all the relevant context or not. > Hence, please also refrain from reiterating your point: I think it has > already been documented there quite extensively. I disagree. There is not one point, there's several dozens of points. Most of those I haven't even written about. Conflicts between people are complex, which is why lawsuits take so long. The particular point of the libgit.a discussion in 2013 is not something I had already documented, so I'm not reiterating it, especially not here. My intention is not to flood the mailing list or reiterate anything. If nobody responds anymore, neither would I. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s0u643UwArfYVh741MX%2Bme6zn8JOQ3MG6JET9YHO%3DHiag%40mail.gmail.com.
Re: [git-users] [ANNOUNCE] git-fc 0.1: new fork of git for users
On Tue, May 23, 2023 at 9:25 AM Konstantin Khomoutov wrote: > > On Mon, May 22, 2023 at 05:12:04PM -0600, Felipe Contreras wrote: > > > git-fc is a fork of Junio Hamano's git. > [...] > > Take for example the "staging area", a term literally > > everyone agrees [1] is superior to "the index". Not just people from the > > teaching industry, but even the Pro Git book (which isn't endorsed by > > Junio), countless tutorials, and even Git developers themselves. Not one > > Git developer is against the term... except Junio. > [...] > > Even Linus Torvalds argued for a `git update` command that does a > > fast-forward by default [2]: > [...] > > Junio once again chose to ignore all the proposals to improve > > `git pull`. > [...] > > Junio himself shot the door to any sort of collaboration, since he > > permanently banned me from the project with no warning and no recourse > > whatsoever for simply daring to disagree with him [5]. > > > > After 15 years of contributions, he didn't even pretend to conduct a > > fair process in which I would receive a warning and an opportunity to > > defend myself. I received **nothing**. Not even a single reply notifying > > me that they (the Git PLC) wouldn't respond to me anymore: I patiently > > waited several days for a reply until I realized it was never going to > > come. They just sent a singe email notifying me of the permanent ban, > > ignored my requests for clarification, and that was that. > [...] > > [5] > > https://felipec.wordpress.com/2023/05/16/my-ban-from-the-git-project-the-defense-i-was-denied/ > [...] > > For completeness, there's the link to a message which can be served as an > entry point to a different view on these matters which is also present in the > Git developers' community [7]. > > I should note that I do not have a strong opinion on this situation (or at > least I do not have an opinion I'd like to share) - merely trying to make it > possible to be able to see a more complete picture for those who finds it > interesting. > > 7. > https://lore.kernel.org/git/20230511012558.ga1464...@coredump.intra.peff.net/ Needless to say these are Jeff King's *opinions*, these are not facts. If you don't fall for the Gish gallop [1] strategy and actually read the thread of the first link [2], you would realize nobody had a problem with what I was saying, not even Jeff King. It was only Junio. Linus Torvalds said what I was doing was bikeshedding, but even Junio disagreed and corrected him. The important detail is not that Junio asked me to leave in 2013, it's *why*. If you actually read the 59 messages of the thread, you can see that he asked me to leave because I dared to suggest libgit.a was not an actual library, and the organization of the code makes an actual library virtually impossible, which is something even Google developers are saying now in 2023 [3]. Of course Jeff King is counting on people not reading the context of the discussions that happened one decade ago and simply assume Junio had a good reason, when in fact he didn't. But all this personal drama from 2013 is irrelevant to a technical discussion in 2023. Junio tried to introduce a change that was backwards-incompatible two weeks ago. That's a fact. All I did is point that out. Personal drama from 2013 is merely a *distraction* from the technical discussion, in which I showed Junio was wrong, and I was right. Sadly they can't focus on the technical discussion. Cheers, [1] https://en.wikipedia.org/wiki/Gish_gallop [2] https://lore.kernel.org/git/7vsj0lvs8f@alter.siamese.dyndns.org/ [3] https://lore.kernel.org/git/CAJoAoZ=Cig_kLocxKGax31sU7Xe4==bgzc__bg2_pr7krnq...@mail.gmail.com/ -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s1AeRmE%2B_DhVT2DFJFrU9vsqG7%2BS3k%2BB4tmN7LC5AsfUQ%40mail.gmail.com.
Re: [git-users] [ANNOUNCE] git-fc 0.1: new fork of git for users
On Tue, May 23, 2023 at 1:21 AM Uwe Brauer wrote: > >>> "FC" == Felipe Contreras writes: > > > git-fc is a fork of Junio Hamano's git. > > It's targeted to the users of the git tool. > > > Completely forking the code opens the doors to many possibilities, for > > example moving to saner defaults, such as zdiff3 and rebase preserve > > merges. Using libgit2, or rewriting the commands to Rust or another > > modern language. Also moving to a modern asciidoctor documentation, and > > rewriting it for humans. > > Very interesting. > > 1. Do you have any plans to include the branch.tail feature, you >proposed several weeks ago to Hamano, but got refused, if I am not > mistaken. Perhaps. There's many features I would like to port first. Once that's done I might consider implementing this properly. But Junio didn't refuse the proposal, he just didn't respond anymore. He often does that: initially shows interest in a proposal, then ignores it. > 2. Can you point out a link to me, how for the official git version >deb pkg are generated? I usually produce my own pkg, by >converting tgz, which is not a proper way of doing things for an >official release. It's been a while since I've built a debian packages, but you can find the official source package (Download Source Package): https://packages.debian.org/bullseye/git I believe "git_2.30.2-1+deb11u2.debian.tar.xz" is what contains the debian-specific stuff. You might have more luck in a #debian IRC channel. But you don't actually need a package, you can install git anywhere you want, I use /opt/git: make prefix=/opt/git install Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3W%3D0Tr0f9HwL1xb%2BS5fgXsyLDZ4tXvjUVQxzwVDpHmLg%40mail.gmail.com.
[git-users] [ANNOUNCE] git-fc 0.1: new fork of git for users
serve
merges. Using libgit2, or rewriting the commands to Rust or another
modern language. Also moving to a modern asciidoctor documentation, and
rewriting it for humans.
Keep in mind that these are not my ideas, these are ideas that have been
discussed for many years. Just recently Google announced a project to
convert parts of the code to a library [6], a project which after years
of work (both internal and public) doesn't show any light at the end of
the tunnel. And of course Junio has provided *zero* support for.
---
Linus Torvalds created git with the promise of being the first truly
open source *distributed* version control system.
Today there's zero members of the open source community contributing to
the git project regularly. All of the regular developers are being paid
by big corporations to improve the efficiency of their server solutions.
The last community contributor championing for the needs of users
(i.e. me) was permanently banned with no recourse using "rudeness" as
an excuse, when the maintainer himself is much more rude regularly, as
you can see in my defense [5] I was not allowed to present.
It's very clear that the two areas where git needs the most improvement
are:
* User interface
* Documentation
And it's very clear those are the two areas big corporations care about
the least.
It's time for the open source community to regain control of the project
by doing what distributed version control systems are best used for:
a *fork*.
There is no reason for any user to use Junio's version of git, which has
no UI improvements to speak of since at least the last decade. Junio's
git is for GitHub servers, not users.
git-fc 0.1 has more improvements to the UI in its initial release than
Junio's git has had in the past 10 years, and this is just the
beginning, as I have literally hundreds of patches that Junio has
ignored over the years.
Why not give it a try?
https://github.com/felipec/git
For Arch Linux users I created a package so you can easily replace
Junio's git:
https://aur.archlinux.org/packages/git-fc
Cheers.
Felipe Contreras (135):
stage: add proper 'stage' command
stage: add helper to run commands
stage: add 'add' subcommand
stage: add 'remove' subcommand
unstage: add 'unstage' command
stage: add 'diff' subcommand
stage: add 'edit' command
stage: add prefix test
test: stage: workaround lint bullshit
merge: improve fatal fast-forward message
merge: split cmd_merge()
fast-forward: add new builtin
doc: fast-forward: explain what it is
advice: add diverging advice for novices
fast-forward: add help about merge vs. rebase
update: new built-in
update: add options and usage skeleton
update: add --ff option
update: add --merge mode
commit: support for multiple MERGE_MODE
merge: add --reverse-parents option
update: reverse the order of parents
update: fake a reverse order of parents in message
update: add --rebase mode
update: add mode configuration
update: add per-branch mode configuration
rebase: add REBASE_DEFAULT
test: pull: fix precedence bullshit
pull: move configuration fetches
pull: don't consider --ff options especially
pull: introduce --merge option
pull: add pull.mode
pull: add per-branch mode configuration
pull: add pull.mode=fast-forward
pull: improve --rebase and pull.rebase interaction
pull: remove divergent advice
push: trivial cleanup
fast-forward: update documentation
guideline: allow declaration after statement
Add concept of 'publish' branch
remote: export remote_read_config
remote: add remote_for_each()
readme: use our own
readme: unfriendly fork
readme: add comment about stage
readme: add publish information
branch: add --set-publish-to option
remote: add branch_get_publish
sha1_name: add support for @{publish} marks
for-each-ref: accept "%(publish)" format
branch: prioritize upstream in -v
branch: refactor list format
branch: simplify track info
version-gen: reorganize
version-gen: generate proper interim versions
version-gen: use tags
Rename project to git-fc
gitk: remove support for ancient versions
CoC: remove authoritarian document
github: remove l10n
git-gui: remove support for ancient versions
branch: display publish branch
ref-filter: simplify atom check
remote: add branch.upstream shortcut
push: add --set-publish option
remote: show published status and help
test: remove HTTP/2 test
test: mergetool: unset environment variable
readme: cleanups and fixes
test: fix build for zsh
test: comple
Re: [git-users] after pulling from remote, move last commit into a new branch and push
On Sat, Apr 22, 2023 at 7:53 AM Uwe Brauer wrote: > I pulled for a remote server and obtained > > * commit b7007223bd7c99b9d92911c66411b2143a791ce4 (master) (origin/master, > origin/HEAD, master) > | Author: John Ciolfi > | Date: Mon Apr 10 16:05:31 2023 -0400 > | > | matlab and org mode example > | > > > So I wanted to create a new branch org-mode so that this commit should > be in the new branch and later add other commits to that branch. > > So I run > > git branch org-mode > git checkout master > git reset --hard HEAD~1 > git checkout org-mode > git push -u origin org-mode You pushed the "org-mode" branch, but you changed the "master" branch, and you didn't push it. > * commit b7007223bd7c99b9d92911c66411b2143a791ce4 (master) (origin/master, > origin/HEAD, master) > | Author: John Ciolfi > | Date: Mon Apr 10 16:05:31 2023 -0400 > | > | matlab and org mode example > | > > So commit b7000 belongs to master not to org-mode as I hoped, what did I > miss? You changed the "master" branch locally, but you didn't update it on the remote repository. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3na%2BUBthjPNSx2xuuUzDYkAWn-doHS-M8iAwZ9_7QQ1w%40mail.gmail.com.
[git-users] Re: [Push solved, but pull?] (was: [and remote branch tracking])
On Sat, Apr 22, 2023 at 3:02 AM Uwe Brauer wrote: > So as you can see the git hashed was not copied. > So if I wished to use that repository and push via hg-git I cannot > because hg tells me that there are commits missing and when I pull, he > just pulls everything his way (that is converting git branches into > bookmarks) and so doubling the commits! It's not hg, it's hg-git. I presume you want to pull from a git repository, not from an hg repository. It should be possible to write a script that uses git-remote-hg to clone a hg repository and then leaves it ready for the hg-git plugin to be used on top of it. But I don't understand your use-case. If you want to use hg, then use hg-git, if you want to use git, then use git-remote-hg. You can use git-remote-hg to mirror a git repository and create an hg repository, but you need to keep using git-remote-hg to keep updating that mirror, if you do "hg pull" it would have to be from that mirror, not the original git repository, as that would use hg-git, not git-remote-hg. > I see two solutions here > > 1. Your scripts copies the git hashes. That would be simply great >because it would allow a round trip. Unfortunately, you told me, >that you, stopped the development. Looking at the code my understanding is that the hg-git plugin creates that gitnode information on-the-fly, it's not stored anywhere in the hg repository. So if you remove or disable that hg-git plugin, the information disappears. git-remote-hg does create an exact replica of the hg repository itself, so you can do a round trip. But it's not an hg plugin, so it doesn't provide that gitnode extra information. That's something only an hg plugin can do. I said I stopped development in the past, but I'm working on it again. > 2. I work on the converted repository, but then pull from the git >repository and then push the pull commits to the remote server. >However some questions > >1. If I create a hg named branch and I pull it, will it be > translated into a git branch. > >2. What happens if I use the evolve extensions (which hides > certain commits), would everything pulled, or would the hidden > be ignored (as say should be). I don't know. I would need to see an example. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s1ZGvphRdogya6nob61%2BR88wJrg8TGVhGuKb9FhPwK7cw%40mail.gmail.com.
[git-users] Re: [and remote branch tracking]
On Tue, Apr 18, 2023 at 1:03 AM Uwe Brauer wrote: > > > On Mon, Apr 17, 2023 at 3:05 PM Uwe Brauer wrote: > > > git push hg-remote > > remotes/origin/modernize:refs/heads/branches/modernize > > Does not push the git branch modernize to the named branch modernize, sorry It does here. ( git init git-repo cd git-repo echo one > content git add content git commit -m 'one' ) hg init hg-repo ( git clone git-repo proxy-repo cd proxy-repo git remote add -f hg-repo hg::../hg-repo git push hg-repo remotes/origin/master:refs/heads/branches/master ) hg -R hg-repo log changeset: 0:c8ae0e6c7f3e branch: master tag: tip user:Felipe Contreras date:Tue Apr 18 02:08:35 2023 -0600 summary: one > > Only if you don't specify the refspec, which is the typical way to push. > > You mean, in layman terms, checkout the remote branch? No, checking out means putting the contents of a revision in the current working directory. This is true in all version control systems, including Mercurial. An alias for `hg checkout` is `hg update`. You don't need to checkout a branch to push it, just do: `git push foo` (no refspec). > > git push hg-remote hairyblocks > > > That would be translated to a refspec: > > > git push hg-remote > > refs/heads/hairyblocks:refs/heads/branches/hairyblocks > > > But if you are already specifying the refspec, nothing gets translated. > > > > It does, but you haven't created the local branches, soyou can't do > > `git push foo`, if "foo" doesn't exist. > > > > But you are going to need to do that only once. > > So to sum it up: > > 1. If I wish to push (remote) gitbranches as hg named branches, I have > first >to check them out to have local ones? That seems the strategy I > followed from the >start, but then I understand your comments, that I can somehow >save that step your find at least a faster way No, you don't need to check them out. What I suggested was to use `git switch` to *create* them. Yes, `git switch` also checks them out, but that's an unnecessary step. You can skip that step by doing `git branch` instead of `git switch` (or `git checkout`). But it doesn't matter, the important thing is that they get *created*. But as I already explained, you don't even need to create them. > So you suggested > > > git for-each-ref --format='git switch %(refname:lstrip=3)' > > refs/remotes/origin > > > > Or you can push the commit of a remote branch: > > > > git push hg-remote remotes/origin/modernize:modernize > > That this would save me to step to checkout the branches, but > > git push hg-remote remotes/origin/modernize:modernize git push hg-remote remotes/origin/modernize:refs/heads/branches/modernize Not git push hg-remote remotes/origin/modernize:modernize And this is orthogonal to `git switch`: either you *create* the local branches, or you don't. If you create the branches with `git switch` (or `git branch` or whatever), then you don't need to specify the refspec in `git push`. If you do not create the branches, then you need a refspec (as explained above). -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s2w0%2BR8D7A8UDFvKR2WFz9AVXVa-ojdfyLbXGwY4KBoSg%40mail.gmail.com.
[git-users] Re: [and remote branch tracking]
On Mon, Apr 17, 2023 at 3:05 PM Uwe Brauer wrote: > > > On Mon, Apr 17, 2023 at 1:19 AM Uwe Brauer wrote: > > > Those are *suggestions* of what you should run. It doesn't do > > anything, and obviously you shouldn't do `git switch HEAD`. > > > The error message is pretty much telling you what to do: > > > git push hg-remote remotes/origin/modernize:refs/heads/modernize > > > Why didn't you try that? > > I did, but the commits where pushed as bookmarks not as named-branches git push hg-remote remotes/origin/modernize:refs/heads/braces/modernize > I thought > git config remote.hg-remote.push 'refs/heads/*:refs/heads/branches/*' > > Would have the effect that I don't need to run > > git push hg-remote > remotes/origin/hairyblocks:refs/heads/hairyblocks:branches/hairyblocks Only if you don't specify the refspec, which is the typical way to push. git push hg-remote hairyblocks That would be translated to a refspec: git push hg-remote refs/heads/hairyblocks:refs/heads/branches/hairyblocks But if you are already specifying the refspec, nothing gets translated. > Or whatever it is. > > I am deeply confused. > > I understood the first (cumbersome) method > > 1. Set up remote: git remote add hg-remote > hg::../mercurial-matlab-emacs-default/ > > 2. Checkout each remote branch > > 3. Run, for example git push default:/branches/default > > So I thought running > git config remote.hg-remote.push 'refs/heads/*:refs/heads/branches/*' > > Would shorten > the command > > git push default:/branches/default > > To > > git push default It does, but you haven't created the local branches, soyou can't do `git push foo`, if "foo" doesn't exist. > If I checkout each branch and push them then everything seems find but > suppose I had 100 branches, I need to checkout each, well But you are going to need to do that only once. > > But you can clone it once, set up all the branches once, push all the > > branches ini order once, and forget about that step. > > > After that you can just pull from one repo and push to another. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s0GJf2z4mCyGsoBnDRA9E4VFctPCcDCUFYCSNC%2BfTQHwA%40mail.gmail.com.
[git-users] Re: [and remote branch tracking]
On Mon, Apr 17, 2023 at 1:19 AM Uwe Brauer wrote:
>
> > On Sun, Apr 16, 2023 at 2:31 PM Uwe Brauer wrote:
>
> > You cannot push a branch you don't have. Obviously.
>
> > But you can create the branches without checking them out, as I
> > already explained:
>
> > git for-each-ref --format='git switch %(refname:lstrip=3)'
> > refs/remotes/origin
>
> Ah, right. Into my HOWTO file *now*.
>
> But after using the command I obtain
>
> git switch HEAD
> git switch copyright
> git switch default
> git switch documentation
> git switch fontlockhang
> git switch hairyblocks
> git switch mac_init
> git switch modernize
> git switch shellcomplete
> git switch strings
> git switch usage1
> git switch wisent-parser
Those are *suggestions* of what you should run. It doesn't do
anything, and obviously you shouldn't do `git switch HEAD`.
> > git push hg-remote remotes/origin/modernize:modernize
>
> Well
> git push hg-remote remotes/origin/modernize:mac_init
> error: The destination you provided is not a full refname (i.e.,
> starting with "refs/"). We tried to guess what you meant by:
>
> - Looking for a ref that matches 'mac_init' on the remote side.
> - Checking if the being pushed ('refs/remotes/origin/modernize')
> is a ref in "refs/{heads,tags}/". If so we add a corresponding
> refs/{heads,tags}/ prefix on the remote side.
The error message is pretty much telling you what to do:
git push hg-remote remotes/origin/modernize:refs/heads/modernize
Why didn't you try that?
> > It's not clear what would be the best thing to do here because you
> > haven't explained your use-case.
>
> In the foreseeable feature, matlab-emacs should be moved to
> github/gitlab and I thought of dealing it with your script (BTW I said
> plugin because hg-git calls itself plugin, but since hg is written in
> python that makes sense).
>
> So I have to clone the repository (from gitlab/github and then use your
> script, while using the mirror option would be possible, it think the
> solution with for-each-ref is what I need)
But you can clone it once, set up all the branches once, push all the
branches ini order once, and forget about that step.
After that you can just pull from one repo and push to another.
--
Felipe Contreras
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/CAMP44s0Dy8UqSGPVYLYYYxPSu7o7pKQV0L%3DHOa%2Bj8-AtfZuHbw%40mail.gmail.com.
[git-users] Re: [and remote branch tracking]
On Sun, Apr 16, 2023 at 2:31 PM Uwe Brauer wrote: > > > On Sun, Apr 16, 2023 at 3:01 AM Uwe Brauer wrote: > > > git-remote-hg, and I wouldn't call it a "plugin", git doesn't have > > plugins. It's just a tool. > > > > I'm not sure what's going on here, as I don't have the code of > > `mygit-push-named-branch`, but I suspect it's doing something like: > > > git push hg-remote strings:branches/strings > > > If that's the case I think I already explained to you that you don't > > need to specify the refspec (strings:branches/strings), if the local > > branches have the same name as the remote branches, so you should > > probably name them like "branches/strings", not "strings". > > > Alternatively you can configure git to always push local git branches > > to hg branches: > > > git config remote.hg-remote.push refs/heads/*:refs/heads/branches/* > > > So when you do > > > git push hg-remote strings > > > It will automatically do the equivalent of: > > > git push hg-remote strings:branches/strings > > > Once you have configured git to automatically push to the right > > location, you can push all the branches with; > > > git push --all > > > You don't need to checkout a branch to push it. > git branch -a > > * default > remotes/hg-remote/branches/default > remotes/origin/HEAD -> origin/default > remotes/origin/copyright > remotes/origin/default > remotes/origin/documentation > remotes/origin/fontlockhang > remotes/origin/hairyblocks > remotes/origin/mac_init > remotes/origin/modernize > remotes/origin/shellcomplete > remotes/origin/strings > remotes/origin/usage1 > remotes/origin/wisent-parser You cannot push a branch you don't have. Obviously. But you can create the branches without checking them out, as I already explained: git for-each-ref --format='git switch %(refname:lstrip=3)' refs/remotes/origin Or you can push the commit of a remote branch: git push hg-remote remotes/origin/modernize:modernize It's not clear what would be the best thing to do here because you haven't explained your use-case. Normally people push their branches, that they have in the their repos. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s1%3DmKS9xd69h8bzLcYoTzknM-xPP%3DxbnpqgXWPaUWwjcw%40mail.gmail.com.
[git-users] Re: [and remote branch tracking]
On Sun, Apr 16, 2023 at 6:15 AM Uwe Brauer wrote: > > >>> "FC" == Felipe Contreras writes: > > > On Sun, Apr 16, 2023 at 3:01 AM Uwe Brauer wrote: > >> > >> > git for-each-ref --format='git switch %(refname:lstrip=3)' > >> > refs/remotes/origin > >> > > > git-remote-hg, and I wouldn't call it a "plugin", git doesn't have > > plugins. It's just a tool. > > > Ok. > > > >> I need to do a lot of pushes from git branch to mercurial named-branches > >> like > >> > >> git remote add hg-remote hg::../mercurial-matlab-emacs-default > >> git checkout strings > >> mygit-push-named-branch strings > > > I'm not sure what's going on here, as I don't have the code of > > `mygit-push-named-branch`, but I suspect it's doing something like: > > Sorry it is an alias. > > git push hg-remote strings:branches/strings > > Precisely. > > > > If that's the case I think I already explained to you that you don't > > need to specify the refspec (strings:branches/strings), if the local > > branches have the same name as the remote branches, so you should > > probably name them like "branches/strings", not "strings". > > > Alternatively you can configure git to always push local git branches > > to hg branches: > > > git config remote.hg-remote.push refs/heads/*:refs/heads/branches/* > > > Well that does not work it gives be the following error. > git: No match. At which time? When you do `git config`? Then it's probably your shell globbing git config remote.hg-remote.push 'refs/heads/*:refs/heads/branches/*' > > So when you do > > > git push hg-remote strings > > > It will automatically do the equivalent of: > > > git push hg-remote strings:branches/strings > > > Once you have configured git to automatically push to the right > > location, you can push all the branches with; > > > git push --all > > But what's about the correct order, I mean shall I push master first > then the others, or those which (approximately) were created first? It depends on your topology, "master" most definitely you should push first, but perhaps only the first time. If you have branches with commits in common, for example: master | *--*---* topic-a \ *-* topic-b Then you would need to push one before the other (the first time), in this case presumably topic-a, since topic-b branched off from topic-a. > Because I do remember in one mail you said the order which branch to > push first is somehow important, or I misunderstood you. Yes, if you are creating a new repository by pushing branches, it does matter the first time. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3OWDEm4yaXbXu07GJ644ekwSZkUKGqXHXzRRG%3DQonmvw%40mail.gmail.com.
[git-users] Re: [and remote branch tracking]
On Sun, Apr 16, 2023 at 3:01 AM Uwe Brauer wrote: > > > git for-each-ref --format='git switch %(refname:lstrip=3)' > > refs/remotes/origin > > Changing slightly the topic, when I am using your git-hg-remote plugin git-remote-hg, and I wouldn't call it a "plugin", git doesn't have plugins. It's just a tool. > I need to do a lot of pushes from git branch to mercurial named-branches > like > > git remote add hg-remote hg::../mercurial-matlab-emacs-default > git checkout strings > mygit-push-named-branch strings I'm not sure what's going on here, as I don't have the code of `mygit-push-named-branch`, but I suspect it's doing something like: git push hg-remote strings:branches/strings If that's the case I think I already explained to you that you don't need to specify the refspec (strings:branches/strings), if the local branches have the same name as the remote branches, so you should probably name them like "branches/strings", not "strings". Alternatively you can configure git to always push local git branches to hg branches: git config remote.hg-remote.push refs/heads/*:refs/heads/branches/* So when you do git push hg-remote strings It will automatically do the equivalent of: git push hg-remote strings:branches/strings Once you have configured git to automatically push to the right location, you can push all the branches with; git push --all > git checkout modernize You don't need to checkout a branch to push it. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s0cgvCDZAURG592JDWN6ccZqtB%3Dpgw2cS3cD6M_O3DZWA%40mail.gmail.com.
Re: [and remote branch tracking] (was: [git-users] what is the most efficient way to mirror a repository)
espace, so your local branches are remote tracking branches. If you do changes on a "feature" branch, they will be overridden when you do `git fetch`. Once a mirror, always a mirror. > Is this so far correct? Yes, but I think you should forget about using a mirror, that's not what you want. I think what you want is to mirror all the remote branches only once, and otherwise have a normal repository (not a mirror). You can do that with this command: git fetch origin refs/heads/*:refs/heads/* This will create local branches for all the remote branches (the remote refs/heads/foo will become a local refs/heads/foo). The problem with this approach is that the local branches will not track the remote branches. At the end of the day I think what you should do is do `git switch` for every remote branch, which git can help: git for-each-ref --format='git switch %(refname:lstrip=3)' refs/remotes/origin Just remove HEAD and "master", or whatever branches you have already tracked. Cheers. [1] https://felipec.wordpress.com/2013/09/01/advanced-git-concepts-the-upstream-tracking-branch/ -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s2ApNcWugvu4%3DJFmycAQGV553wUa65ue-O3XBjpOGeDyQ%40mail.gmail.com.
Re: [git-users] what is the most efficient way to mirror a repository
On Fri, Apr 14, 2023 at 3:25 PM Uwe Brauer wrote: > > 1. Clone the original repo: > > > git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src > > > That worked as I expected (as a mercurial user) > I just followed the instructions of the gitlab documentation but did not > realize that this instructions were aimed as users you have set up their > own local repository but not a mirror. Git is a true *distributed* version control system, so everyone's repositories can be thought of as forks. I have many repos where my master branch is not the upstream master branch, it contains other commits, and as such it's a true fork. Maybe `git fork` would have been a better name for `git clone`. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3OMx7JMQTY0nLr2FwLsyQ4k3-EsaXCtoeHLVYp3%3Dx0Zw%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Wed, Mar 22, 2023 at 2:37 PM Uwe Brauer wrote: > > >>> "FC" == Felipe Contreras writes: > > > On Thu, Mar 16, 2023 at 3:26 PM Uwe Brauer wrote: > >> > I wrote the equivalent of hg-git for the git world: git-remote-hg [1], > >> > and there exporting named branches works fine. They have the > >> > "branches/" prefix and only one head is tracked. > >> > >> Do you mean exporting named hg branches into git branches? Yes that > >> seems ok, the other way around is the challenge, > > > No, I mean from git to hg. > > > If a ref has a "branches/" prefix, it's considered an hg branch, and > > all the commits pushed to that branch get tagged. > > Let me try to get this straight. > > 1. Suppose there is a mercurial repository in say sourceforge, that >contains two named branches:, default and stable. > > 2. You clone that repository with your plugin into a git repository. >I presume the named branches end up in the corresponding git >branches. Yes. "branches/default", and "branches/stable". > 3. You make two commits on default and three commit on the stable branch. > > 4. You push (since you have write access), and all commits end up >in the correct named hg branch? Yes. > 5. What happens if you create an additional git branch, say bug-fix >and make a couple of commits and push. Do they end up as a new >named branch called bug-fix, or as a bookmark, or can you chose >between both? If it's named "bug-fix" it's created as a bookmark, if it's named "branches/bug-fix", it's created as a branch. But since Git has the notion of refspecs, you can choose on the fly: git push origin bug-fix:branches/bug-fix > 6. What's about topics, do you also support these? No. I stopped working on git-remote-hg for a while, and topics came afterward. I haven't investigated how to implement them, but it would be nice. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3CbZYW-GH587z00X1xp8Mx%2BLEKgmsKhB%3DbaoxbhKsV-Q%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Thu, Mar 16, 2023 at 3:26 PM Uwe Brauer wrote: > > I wrote the equivalent of hg-git for the git world: git-remote-hg [1], > > and there exporting named branches works fine. They have the > > "branches/" prefix and only one head is tracked. > > Do you mean exporting named hg branches into git branches? Yes that seems ok, > the other way around is the challenge, No, I mean from git to hg. If a ref has a "branches/" prefix, it's considered an hg branch, and all the commits pushed to that branch get tagged. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3aNptf%3DjZNAwM%2B-su63vh6%2B-wrMtDeS%2BewNiy22Yr3ug%40mail.gmail.com.
Re: [git-users] Perl dependency
On Fri, Mar 17, 2023 at 8:37 PM kai.h...@gmail.com wrote: > Is there an effort to remove the Perl dependency? There's a general push to move from scripts to C code, that's mainly about shell code, but I guess perl as well. > Couldn't find anything about it upon > https://github.com/git/git-scm.com/issues?q=is%3Aissue+is%3Aopen+perl or > https://git-scm.com/search/results?search=Perl > > I'm told on IRC #git "2.40 I believe the only thing written in perl is git > send-mail" but I couldn't find any mention of Perl in the release notes [1] > either. These are the scripts I see in the Makefile: git-archimport.perl git-cvsexportcommit.perl git-cvsimport.perl git-cvsserver.perl git-send-email.perl git-svn.perl The only one I use is git-send-email, which I've wanted to rewrite in Ruby for a while, but it's probably not acceptable by upstream. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s24dmZya4CpiTGzfUaK3MrPtWKG%2BPbgvL%2Bth_9Wxq7TvA%40mail.gmail.com.
Re: [git-users] Remote helper connect --force argument
On Fri, Mar 17, 2023 at 4:57 AM Rafael Páez Bastida wrote: > I am working remote helper for git. The helper only supports option and > connect capabilities. > > Push --force... command triggers option progress true, option verbosity 1 and > connect git-upload-pack, but there is no option force, so the helper does not > know that --force was included as an argument. Did you specify "feature force"? I think this question is more suited to the development mailing list. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3mxt_5An0CjxwTXukhAjqCdQ0A-J-CGMcxT08eJC%3DxZw%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Sat, Mar 11, 2023 at 1:11 PM Uwe Brauer wrote: > > > On Thu, Mar 9, 2023 at 8:07 PM Felipe Contreras > > wrote: > > > FWIW I updated the patches and sent them to the dev mailing list so > > they stay on the record: > > > https://lore.kernel.org/git/camp44s0cbum1jzyp57ninikwsxg9kugbkdaoozmnen1akvg...@mail.gmail.com/T/#t > > I just skimmed over the thread. It seems that the reactions were not > negative, so there is some hope. You are a much more positive person than me. I've had countless discussions with positive reactions who lead to nothing. It seems this is going to be another one of those. After just one reply it has been completely ignored. I guess if Google or Microsoft isn't going to pay for this no git developer is going to bother taking a look at it. > Concerning mercurial topics, well it is part of the evolve extension, > which is not part of mercurial core, but on the other hand the evolve > extension is now quite stable so I would not call it experimental, but > anyhow never mind. > Exporting named branches to git branches (for the hg-git extension) is > unfortunately experimental. I wrote the equivalent of hg-git for the git world: git-remote-hg [1], and there exporting named branches works fine. They have the "branches/" prefix and only one head is tracked. Of course they are not commit labels like in hg, but a hack can be enabled to store the name of the branch on every commit like hg-git does with the hg-git-compat option. I don't personally care about that but the option is there for those who do. Cheers. [1] https://github.com/felipec/git-remote-hg -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3A3JJ8TG%3D9jGHE4bz_-HeGHry7At6igghGNg6Kcf9maw%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Thu, Mar 9, 2023 at 8:07 PM Felipe Contreras wrote: > > On Wed, Mar 8, 2023 at 2:28 PM Uwe Brauer wrote: > > > > > On Mon, Mar 6, 2023 at 3:03 PM Uwe Brauer wrote: > > And it seems that in > > https://felipec.wordpress.com/2013/08/27/analysis-of-hg-and-git-branches/ > > > > (https://github.com/felipec/git/commits/fc/base is a dead link) > > I've updated the link, it changed to fc/tail [1]. FWIW I updated the patches and sent them to the dev mailing list so they stay on the record: https://lore.kernel.org/git/camp44s0cbum1jzyp57ninikwsxg9kugbkdaoozmnen1akvg...@mail.gmail.com/T/#t Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s2hFey5gVd%3DXTmHpx5ROQYkn4UdtvTub3txiSTu8Sw13A%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Wed, Mar 8, 2023 at 2:28 PM Uwe Brauer wrote:
>
> > On Mon, Mar 6, 2023 at 3:03 PM Uwe Brauer wrote:
> > It's probably never going to be. The point is that you wouldn't need
> > named branches if you knew from where a branch started.
>
> I am a bit confused, in an earlier mail you said
>
> ,
> | But there are some corner cases in which git is not able to provide
> | the same information as mercurial, because it doesn't have the branch
> | point (the precise point where a branch was created). There's many
> | potential ways to calculate this branch point [2], but there isn't a
> | single infallible solution.
> |
> | Git truly needs to be fixed in order to support this, I proposed a
> | branch@{tail} notation [3].
> `
You could say my relationship with Git developers is complicated. Even
though I do a ton of Git development (maybe the person that does the
most for free), I wouldn't consider myself a "Git developer" ™.
So it doesn't matter if I (and many people) consider such feature
useful, it won't be merged.
> And it seems that in
> https://felipec.wordpress.com/2013/08/27/analysis-of-hg-and-git-branches/
>
> (https://github.com/felipec/git/commits/fc/base is a dead link)
I've updated the link, it changed to fc/tail [1].
> Your proposed a patch and said it was not that difficult.
It's not.
The difficulty relies not on the implementation, but convincing Git
developers that this is useful (even needed).
> > This is hypothetical of course, in truth all you get is what `git
> > name-rev` gives you.
>
> A part from my personal preference to have it, I would also say that
> could be very useful for improving hg <--> git export/import.
Indeed. I don't like Mercurial, but being forced to work with it has
made me see areas of improvement within Git, and this is one of them.
Cheers.
[1] https://github.com/felipec/git/commits/fc/tail
--
Felipe Contreras
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/CAMP44s1SBEsNjOzp3PaJZLhMuO4vvM2wTP9kLxBMBrQ4ASfHKA%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Mon, Mar 6, 2023 at 8:41 AM Uwe Brauer wrote:
>
>
> > On Sat, Mar 4, 2023 at 1:39 AM Uwe Brauer wrote:
>
> > It's calculated on the fly.
>
> Ok, that I was afraid of.
>
> > Weirdly enough, I wrote a blog post [1] about a debate in 2012
> > precisely about the differences between git and mercurial, and how
> > `git name-rev` can be used to simulate mercurial branches (for the
> > most part).
>
> > But there are some corner cases in which git is not able to provide
> > the same information as mercurial, because it doesn't have the branch
> > point (the precise point where a branch was created). There's many
> > potential ways to calculate this branch point [2], but there isn't a
> > single infallible solution.
>
> > Git truly needs to be fixed in order to support this, I proposed a
> > branch@{tail} notation [3].
>
> That would be great, in the meantime name-rev is good enough for me in
> most cases. I have to admit that for larger repositories I still feel
> more comfortable using mercurial (one of the reasons is named branches)
>
> Now since quite a while the hg-git converter exports named branches to git
> branches (although that is still not officially supported)
>
> The problem is how to import git branches into named branches (right now
> they are converted to mercurial bookmarks).
> The problem is if name-ref is calculated by git on the fly, then one
> would need somehow first pull with the git the repository and then
> import the local repository to mercurial.
Yes, git branches are more akin to hg bookmarks, although nowadays
there's the concept of hg topics, which is even closer.
I've personally never needed some sort of per-commit label (hg
branches), but sometimes I've lacked some marker to where a git branch
was started from. I believe that's the only instance in which hg
branches might give some benefit, but the same could be achieved with
branch@{tail}.
If branch@{tail} was available git name-rev would provide *exactly*
the same information as hg branches (in useful cases).
Cheers.
--
Felipe Contreras
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/CAMP44s338dG3%3DE7tpxN-aYkrgx_qr2hjrWXWpAqmz%3Do0NEEYnQ%40mail.gmail.com.
Re: [git-users] how is name-rev determined
On Sat, Mar 4, 2023 at 1:39 AM Uwe Brauer wrote:
> However a solution is to use name-rev
>
> Like this
>
> git log --graph --color=always --all --since=2years --decorate --pretty |
> git name-rev --annotate-stdin | less -R
>
> And the resulting graph looks, at least for me, close enough to
> mercurial's named branches.
>
> So I am wondering, is this name-rev information somewhere stored, or
> calculated on the fly each time the command is called?
It's calculated on the fly.
Weirdly enough, I wrote a blog post [1] about a debate in 2012
precisely about the differences between git and mercurial, and how
`git name-rev` can be used to simulate mercurial branches (for the
most part).
But there are some corner cases in which git is not able to provide
the same information as mercurial, because it doesn't have the branch
point (the precise point where a branch was created). There's many
potential ways to calculate this branch point [2], but there isn't a
single infallible solution.
Git truly needs to be fixed in order to support this, I proposed a
branch@{tail} notation [3].
But for now `git name-rev` is good enough.
Cheers.
[1]
https://felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/
[2] https://stackoverflow.com/questions/1527234/finding-a-branch-point-with-git
[3] https://felipec.wordpress.com/2013/08/27/analysis-of-hg-and-git-branches/
--
Felipe Contreras
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/CAMP44s3J9CjWCaDoo8A3MM-eu%3D%2BToX2S1KRfs%2B1O3nw0V8BKuw%40mail.gmail.com.
[git-users] git-completion 1.2 released
Hello,
Git-completion is a friendly fork of the official Git completion and
prompt scripts for Zsh and Bash.
The main goal is to provide a more up-to-date completion for Zsh (I'm
the developer), which is basically just a wrapper around the Bash
completion.
Compared to Git upstream, you get many benefits for Zsh, for example:
no extra unnecessary spaces, correct auto suffix removal, colors
without PROMPT_COMMAND, custom aliases, fixed --no-options, and many
more.
There's also benefits for Bash users too, mainly plenty of bug fixes.
If you use the official Zsh completion the main benefit is that it's
blazingly fast. Simply doing "git log " on the Linux kernel (with
3k+ refs) takes several seconds on the official Zsh completion (about
3 seconds on my machine), with git-complete it's *instantaneous*.
There's other benefits too. Since the Bash completion is actively
maintained by Git developers, everything works as they intend too.
For example "git send-email " correctly completes branches, as
opposed to files in the Zsh official completion. Also, complex aliases
such as '!f () { }; f' are correctly identified and completed
out-of-the-box.
It's a sister project of the Oh My Zsh gitfast plugin [2], which I maintain too.
Since the last version a testing framework was added, and now all the
completion tests of the Git project pass with the Zsh wrapper too [3].
For installation instructions, and more information, check the wiki
[1], but basically.
* make install
* fpath=(~/.local/share/git-completion/zsh $fpath)
Enjoy.
[1] https://github.com/felipec/git-completion/wiki/Zsh
[2] https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gitfast
[3] https://travis-ci.org/github/felipec/git-completion
--
Felipe Contreras
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/CAMP44s3_PQHtLPGPOqEsMKgk_D_S8C73b_PmprAruJJEYhcfog%40mail.gmail.com.
[git-users] Re: Too much spam
On Sat, May 24, 2014 at 6:55 AM, Thomas Ferris Nicolaisen wrote: > On Friday, May 23, 2014 1:09:10 PM UTC+2, Felipe Contreras wrote: >> I'm just letting you know that there's way too much spam in this list >> to my liking, so I'm unsubscribing. > > Not sure if you saw it, Felipe (on cc), but in the other thread Patrick > wrote "updated the group to require moderation for first posts by new > members.". Yeah, I saw that. I'll subscribe again to see if everything is indeed OK. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Too much spam
Hi, I'm just letting you know that there's way too much spam in this list to my liking, so I'm unsubscribing. I don't understand why the admins don't want to solve the problem. I maintain mailing lists with similar levels of spam, and it's very easy to enable moderation and simply screen every message that is posted by a non-member. If it's good allow the author and his further messages, if it's not, mark it as spam and ban the author. This is a little extra work from the admins, but it's much more work for the thousands of members to constantly mark the messages as spam. Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Re: MONSTRUOS PEDOPHILE & MEGA MAFIA MONEY LAUNDERER DAVIDE SERRA ALGEBRIS IS INFILTRATING PD TO KILL IT! PRO NAZIST DICTATOR, PRINCIPAL OF MURDERS & SLAUGHTERS, MAFIOSO, THIEF, CORRUP
On Mon, May 19, 2014 at 10:19 AM, Dale R. Worley wrote: >> From: ALFREDO PIACENTINI SYZ GENEVE >> >> Op zondag 11 mei 2014 19:08:32 UTC+2 schreef FEDERICO TRABUCCO KAIROS MILAN: >> > >> > MONSTRUOS PEDOPHILE & MEGA MAFIA MONEY LAUNDERER DAVIDE SERRA ALGEBRIS IS >> > INFILTRATING PD TO KILL IT! PRO NAZIST DICTATOR, PRINCIPAL OF MURDERS & > > So now we're getting into reruns? Enable moderation already. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] strange issue related to rebase.
On Mon, May 12, 2014 at 10:50 PM, Felipe Contreras wrote: > I've been thinking about this and I think it's the wrong thing to do. > I'll disable this "feature" by default in my fork (git-fc). Here it is: https://github.com/felipec/git/commit/0e59c7f2eef2e675098b4412ff0f65f0023126e8 -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] What is the best way to visualize branch history line?
On Tue, May 13, 2014 at 9:19 AM, Konstantin Khomoutov wrote: > On Tue, 13 May 2014 09:47:40 -0400 > wor...@alum.mit.edu (Dale R. Worley) wrote: > >> > What would be the best command to view a branch history? >> >> "git log --graph" helps my intuition. > > Agreed. I have `git overview` alias set to > > git log --graph --all --decorate --oneline > > to get an overview of "the current state". > > Not what the OP wants (he needs --diffstat etc) but the general idea is > to use `git log --graph`. If the user wants to see everything, yes, but to me it looked he was interested in the sequence of events, so --graph is not the best for that. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] What is the best way to visualize branch history line?
On Mon, May 12, 2014 at 9:20 PM, Leonardo Petry wrote: > What would be the best command to view a branch history? Right now I use git > show-branch but I get a huge list of commits and branches. Ideally I would > like to see a couple of previous commits and be able to see the which files > where added to each commit. Probably `git log --decorate --oneline --diffstat`, or something like that. There's tons of options to `git log`. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] strange issue related to rebase.
On Mon, May 12, 2014 at 9:15 AM, wrote: > But I wanted to know what wrong I did here, Why git skipped my commit > silently. I got hit by something like this today. If the issue is the same I got, doing `git merge-base --fork-point origin/master 87f93aa ` should return 87f93aa . If so, most likely doing a `git reflog origin/master` would show 87f93aa in the list. Judging from the fetch message, 87f93aa was indeed on the server side. So this is what I think happened: 1) You pushed your lost commit to the server 2) Somebody pushed a different head and overrode your commit 3) You try to rebase on top of the new head 4) Git is trying to be too smart and thinks you want to rebase from a previous point of origin/master This fork-point feature was introduced recently. I've been thinking about this and I think it's the wrong thing to do. I'll disable this "feature" by default in my fork (git-fc). Cheers. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] strange issue related to rebase.
On Mon, May 12, 2014 at 1:42 PM, Philip Oakley wrote: >> tabdulradi@radian-XPS:~/workspace/myproject$ git pull --rebase >> remote: Counting objects: 66, done. >> remote: Compressing objects: 100% (60/60), done. >> remote: Total 66 (delta 4), reused 25 (delta 0) >> Unpacking objects: 100% (66/66), done. >> From github.com:CompanyAccount/myproject >> + 87f93aa...629fe47 master -> origin/master (forced update) > > This "forced update" suggests you have your refspecs configured to do an > overwrite on the fetch stage, so you would loose you own local commits if > they aren't on a separate branch. That's not true. His local commits are in "master", not "origin/master". All systems have configured forced updates for remote tracking branches. It's normal for "origin/master" to be overridden. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Maintaining two loosely coupled repositories
On Sat, May 3, 2014 at 6:41 AM, Jason Curl wrote: > On Sat, May 3, 2014 at 1:11 PM, Felipe Contreras > wrote: >> I often do something similar. I think the easiest is to export GIT_DIR >> to the repository you want to update, and then change directory where >> you have the content you want to compare. >> >> You can do 'git diff' and 'git add' and 'git commit' and GIT_DIR repo >> will be updated. >> > As I've only started using git yesterday (migrated everything from SVN to > GIT and made some inroads), do you have an example, or could point to a > tutorial? So, for example I have Git repository called 'dotfiles' where I track the configurations in my $HOME. Many people have those repositories[1]. I have it in ~/dotfiles, but the real location of the Git directory is ~/dotfiles/.git. So I go to my home directory and do this: % export GIT_DIR=~/dotfiles/.git Now I can do `git diff` and see that for example my .alias file has modifications I don't have in my git repository, so I can do `git add .alias` and `git commit`. [1] https://github.com/search?q=dotfiles -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Maintaining two loosely coupled repositories
On Sat, May 3, 2014 at 5:52 AM, Jason Curl wrote: > I have two repositories, one local, another one published (e.g. on > CodePlex). The local repository is a large codebase and forms part of a > framework, the published repository is a subset only contains about 5%. For > the files that differ, they do so in a minor way (comments, namespaces, > etc.). > > How can I (a) determine if a repository has changed since my last merge; and > (b) merge between the two repositories so changes in either get pushed back? I often do something similar. I think the easiest is to export GIT_DIR to the repository you want to update, and then change directory where you have the content you want to compare. You can do 'git diff' and 'git add' and 'git commit' and GIT_DIR repo will be updated. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] How to list branches
On Fri, Oct 18, 2013 at 9:57 PM, Blake McBride wrote: > Thank you very much for the help! I have that book. I think I'll some > reading. My mind is so SVN oriented that when I read the books I keep > thinking 'but how would I do x? y? Z?' Perhaps x, y, and z don't make > sense with this new model. In my opinion Subversion and Git are so different it's not helpful to think on those terms. Yes, some commands are equivalent, but many others seem similar but do drastically different things. > From what you are saying, I gather that branches created remotely are kept > noted as such (even though I have a local copy). When I check the branch > out, it becomes a totally new local branch. Not exactly. 'git checkout origin/foo' is how you checkout a remote branch, but that sends to a kind of limbo called a detached HEAD, which means you are in no branch, you are in a commit, and more often than not that's not what you want. 'git checkout foo' will checkout the local branch 'foo', if there's no local branch with that name it finds out if there's a remote branch with that name that would make sense to checkout, and will replace that command with 'git checkout -b foo origin/foo' (create a new branch 'foo' from the starting point 'origin/foo') -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] How to list branches
On Fri, Oct 18, 2013 at 9:31 PM, Blake McBride wrote: > I now see that the -a list option displays all of the branches. The branch > names are preceded with remotes/origin. Don't know what that means or what > is occurring when I check it out (from the local repository) to make it a > local branch. Again, I am lost. (I come from the subversion world which > seems easy.) I don't understand what is so difficult: 'origin/master' means the 'master' branch in the 'origin' repository. To see the URLs of the remote repositories you can do 'git remote -v'. > Also, now that I can see some sort of branches that were created somewhere > else and have some sort of other status, how can I tell where these branches > were off of and what cross branch merges occurred? Just like you would do with local branches. A command like this usually does the trick: git log --oneline --graph --decorate origin/master...master > I have the available three books on git. What would you recommend in order > to understand all of the above difficulties? Why don't you use the link I sent to the ProGit book chapter about these? It's free. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] How to list branches
On Fri, Oct 18, 2013 at 9:19 PM, Blake McBride wrote: > I appreciate your response, but I don't think it is related to my question. > My local repository is up-to-date as shown. I understand that my query's > are against my local repository. The point is that git first reports one > branch, Because you have only one branch. > and then it reports two, Because you have two. > when nothing has changed in the local repository. Git told you exact what changed: Switched to a new branch 'Version_2_6_10pre' The key word being *new*. To understand what is happening better, instead of 'git branch' do 'git branch --all', then you will see that your notion of Version_2_6_10pre is in fact origin/Version_2_6_10pre, a remote branch, and when you do 'git checkout Version_2_6_10pre' it's creating a *new* local branch that tracks the remote branch origin/Version_2_6_10pre. From Git's point of view, those are two separate branches. You can read more about remote tracking branches in the ProGit book: http://git-scm.com/book/ch3-5.html -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git rebase after a pull
On Sat, Sep 21, 2013 at 8:06 AM, dexter ietf wrote: > is it required to do a git pull before doing a git push. > and is it required to do a git rebase after git pull just > before git push. one of my git repo mandates the > above wondering if there is a valid reason for this. Only if your local changes have diverged. You have to either merge or rebase. 'git pull' by default does a merge, but you can force it to do a rebase: 'git pull --rebase'. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: [PATCH] build: add default configuration
On Sat, Sep 21, 2013 at 1:33 AM, David Aguilar wrote: > Felipe Contreras wrote: >>I know 'git ci' is perfectly fine shortcut to 'git commit'. >> >>Either way, it doesn't matter. Even if we agree that /etc/gitconfig.d >>is what we want, or we add an /usr/share/git/config, Junio is not >>going to apply any patch, even if it's what most users want. > > Please stop making personal attacks that add nothing to your argument. No one > cares. Let it be. There are no personal attacks here. A personal attack would be 'X is a moron', or 'X doesn't know what he is talking about', I don't see any of that. This is a fact, do you see anybody besides you and me commenting about the subject? More specifically, do you see Junio making any comment? > Let's move this in a more constructive direction then, no? > > How about working on documenting the new aliases and add a knob to the > Makefile so that we can choose whether or not to install the stock config? Sure, but document these aliases where? If you mean document them in the man page of each command (e.g. git commit, alias: ci), then sure, that's fine by me. Adding a know to the Makefile I think doesn't make sense, because a packager would do. % make NO_DEFAULT_CONFIG=y install Which is not very different from: % make install % rm -f $DESTDIR/etc/gitconfig > I'm not trying to fight this patch -- the idea is nice. Most users and > distros probably won't change stock aliases, so your energy may be better > spent getting consensus on what the stock aliases could be. Thanks for stating so, unfortunately, I don't think it really matters because this is a change, and the Git project is not welcome to change. > Would it not be better to have these aliases, plus/minus one or two, then > none at all? Yes, but you don't see anybody advocating for that at all, do you? > ... > Yes I know about .rpmsave files. For rpm, it'll refuse to upgrade Git since > this new file will conflict with an existing package. In your case, yes, not in the normal case, where /etc/gitconfig is not provided by a package. > That's easier to deal with because the config package can then be > independently modified to install its file to eg git.d/foo.conf in the > directory include example. That would then allow the upgrade, and at no > point did the intended config ever get lost. It might be easier to deal with, but it would still require an intervention. > Puppet users, for example, may end up with rpmsave turds on their systems, > though. When you are managing lots of machines this can be very annoying -- > that's why I mentioned it. Don't bother arguing this point any further. It's > boring. It can be very annoying, but your /etc/gitconfig.d solution doesn't help in that regard. Either way, the move from 'git-foo' to 'git foo' was very annoying as well, but we all agreed it was the right thing to do (most of us), fortunately in this case I think the people that have a /etc/gitconfig are significantly less. > ... > In summary -- makefile knob, please, and at least mention the stock aliases > somewhere in the docs so that the users can know to read /etc/gitconfig if > they want to know more. Who knows, maybe it will get applied, but it > definitively won't if all you do is whine about it. It won't get applied, I'll do the modifications, and you'll see. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: [PATCH] build: add default configuration
On Fri, Sep 20, 2013 at 7:44 PM, David Aguilar wrote: > Felipe Contreras wrote: >>David Aguilar wrote: >>> Felipe Contreras wrote: >>> >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar >>> >wrote: >>> >>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar >>> >wrote: >>> >>>> >>> >>>> Will this not conflict with folks that supply their own >>gitconfig? >>> >> >>> >>> You mean people that provide their own ETC_GITCONFIG? If you mean >>> >> distributions, their packaging would override /etc/gitconfig, if >>you >>> >> mean people that have already a /etc/gitconfig, packaging systems >>> >> usually save the old one so they can solve the conflict manually >>> >(e.g. >>> >> /etc/gitconfig.pacsave). So no, it would not conflict. >>> >> >>> >> Yuck. Yes, that one. I package my own /etc/gitconfig (as we have >>long >>> >advertised as the "way to do it") >>> > >>> >You package /etc/gitconfig *outside* the git package? I don't see >>how >>> >that could have been ever advertised as the way to do it. >>> >>> Okay so how exactly are we supposed to do it? Duh, rpm is the right >>choice for redhat systems. >> >>The same way kerberos, mariadb, apache, and essentially every other >>tool that >>has a configuration file in /etc. > > Good point. These tools (apache, for example) allow inclusion of a directory. Wrong. Apache does, but neither does kerberos, nor mariadb, which have a single configuration file, at least on all the systems I've seen. You act as if you have never seen .pacsave/.rpmsave (and so on) files before, they a are pretty common sight when the user modifies the configuration files, and as kerberos and mariadb demonstrate, pretty successful projects can survive with a simple single configuration file. > Your patch does not add this capability, so by your own definition it's > incomplete. As-is, the patch is half-baked. It's not incomplete, any more than kerberos, mariadb, and countless other programs are. > If we have a clear upgrade path -- eg "move your current configs over to > /etc/git.d/your.conf" -- then it's a non-issue. But now you contradict yourself. This patch would force users to resolve the conflicts eventually through .pacsave/.rpmsave, and with your proposal to have directory includes, it would also force manual user intervention by moving the configuration files and resolve the conflict. So why is one manual user intervention so appalling, and the other one so right? Either way, if this patch is so wrong, then clearly the RedHat packaging team would remove /etc/gitconfig from the Git RPM package, and you would be fine, wouldn't you? Or maybe you are afraid that RedHat packaging team would agree that the /etc/gitconfig file provided by Git is fine. > As-is, you're asking users to manually deal with the fallout. You're also > asking users to modify a package-manager controlled file (after your patch), > which IMO is suboptimal. In both cases the user has to manually deal with the fallout. >>> >Users don't package /etc/gitconfig outside git. >>> >>> Wrong. Existence proof: me. >> >>You as a user are not packaging it, it's you as a system adimistrator. > > Strawman. I represent at least at least a hundred users, but who cares. It > doesn't matter. The patch is incomplete. No you don't, you represent a system administrator, not a user. >>Either >>way, you are 0.0001% of Git's userbase, you are not representative. > > And your point is what exactly? That once proven wrong you move the > goalposts? It's called colloquial language. If I say, "people don't bark on the street", and then you say "here, there's a guy that does bark on the street", and then I say, fine, "people don't *NORMALLY* bark on the street", what have we achieved? This is just an exercise in pedanticism. Sane users, under normal circumstances, for the overwhelmingly vast majority of situations, do not package their /etc/gitconfig file. >>> >>>> I like the idea. Docs? Also, should this not be done in the C >>side >>> >so that we don't waste time reading the config, and also prevent >>users >>> >from overriding these? >>> >> >>> >>> But we want them to be easily readable, and possibly allow >>> >> distributions to easily modify them. >>> >> >>> >> In that case I take it back -
[git-users] Re: [PATCH] build: add default configuration
David Aguilar wrote: > Felipe Contreras wrote: > >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar > >wrote: > >>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar > >wrote: > >>>> > >>>> Will this not conflict with folks that supply their own gitconfig? > >> > >>> You mean people that provide their own ETC_GITCONFIG? If you mean > >> distributions, their packaging would override /etc/gitconfig, if you > >> mean people that have already a /etc/gitconfig, packaging systems > >> usually save the old one so they can solve the conflict manually > >(e.g. > >> /etc/gitconfig.pacsave). So no, it would not conflict. > >> > >> Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long > >advertised as the "way to do it") > > > >You package /etc/gitconfig *outside* the git package? I don't see how > >that could have been ever advertised as the way to do it. > > Okay so how exactly are we supposed to do it? Duh, rpm is the right choice > for redhat systems. The same way kerberos, mariadb, apache, and essentially every other tool that has a configuration file in /etc. > >Users don't package /etc/gitconfig outside git. > > Wrong. Existence proof: me. You as a user are not packaging it, it's you as a system adimistrator. Either way, you are 0.0001% of Git's userbase, you are not representative. > >>>> I like the idea. Docs? Also, should this not be done in the C side > >so that we don't waste time reading the config, and also prevent users > >from overriding these? > >> > >>> But we want them to be easily readable, and possibly allow > >> distributions to easily modify them. > >> > >> In that case I take it back -- I dont like that approach. We want > >consistency, not divergence. This encourages the former. > > > >So you think we have more consistency right now? We don't even have a > >predefined /etc/gitconfig, that creates more inconsistency, as > >everybody's configs and aliases are very very different. > > > >This patch would definitely make things more consistent. > > We don't need this patch to allow distros to modify aliases. Likewise, > allowing the aliases to diverge is less consistent. Do it at a lower level. We already allow the aliases to diverge, we allow it much more. The pach will make the aliases more consistent. > I also agree with Junio's notes about "ci". Something short that can add and > remove from the index would be nice. cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good enough for Git? Yeah, sure. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: [PATCH] build: add default configuration
On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar wrote: >>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar wrote: >>> >>> Will this not conflict with folks that supply their own gitconfig? > >> You mean people that provide their own ETC_GITCONFIG? If you mean > distributions, their packaging would override /etc/gitconfig, if you > mean people that have already a /etc/gitconfig, packaging systems > usually save the old one so they can solve the conflict manually (e.g. > /etc/gitconfig.pacsave). So no, it would not conflict. > > Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long > advertised as the "way to do it") You package /etc/gitconfig *outside* the git package? I don't see how that could have been ever advertised as the way to do it. > and asking users to manually fix up thousands of machines is a bad idea. Users don't package /etc/gitconfig outside git. >>> I like the idea. Docs? Also, should this not be done in the C side so that >>> we don't waste time reading the config, and also prevent users from >>> overriding these? > >> But we want them to be easily readable, and possibly allow > distributions to easily modify them. > > In that case I take it back -- I dont like that approach. We want > consistency, not divergence. This encourages the former. So you think we have more consistency right now? We don't even have a predefined /etc/gitconfig, that creates more inconsistency, as everybody's configs and aliases are very very different. This patch would definitely make things more consistent. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: [PATCH] build: add default configuration
On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar wrote: > Apologies for top post -- anybody have a recommendation for a better app then > maildroid? > > Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. If you mean people that have ~/.gitconfig, then absolutely not, because that one takes precedence. Alternatively, we could have a higher level configuration file (e.g. /usr/share/git/config), but I think that's overkill. > I like the idea. Docs? Also, should this not be done in the C side so that > we don't waste time reading the config, and also prevent users from > overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
