Re: Git trademark status and policy
On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote: > On Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote: > > > > - Commands like "git-foo" (so you run "git foo") are generally OK. > > This is Git's well-known extension mechanism, so it doesn't really > > imply endorsement (on the other hand, you do not get to complain if > > you choose too generic a name and conflict with somebody else's use > > of the same git-foo name). > > > > - When "git-foo" exists, we've approved "Git Foo" as a matching > > project name, but we haven't decided on a general rule to cover this > > case. The only example here is "Git LFS". > > The "Git Cola" project[1][2] provides two fully-featured Git porcelains, > "git-cola" and "git-dag". The DAG tool is never referred to as a > separate project, so shouldn't be a concern trademark wise. > > The project dates back to 2007, while the "Git Cola" name dates back to 2008. > FTR, the name "Cola" is also a shout-out to Linux (comp.os.linux.announce). > > Can we continue to use the name "Git Cola" going forward? Thanks for asking. An official answer will have to involve opinions and a vote from the whole PLC, but let me tell you what _I_ think: - we mostly grandfathered good-faith names that predate the trademark, even if we probably wouldn't grant them today. Searching my mail archives, I see that git-cola did come up (along with a few others like Gitolite and TortoiseGit). And we even ended up with written agreements for some (at the very least GitLab and Gitolite), but I think several (including git-cola) were never officially resolved in anyway. - In my opinion "Git Cola" is a lot less confusing than something like "Git Cloner". Because there is little chance that somebody might say "Ah, the official Cola of Git!". Whereas a generic operational term like "Cloner" does introduce confusion (the "Git" is easily interpreted as "Git presents X" and not "this is an X for using with Git"). So my opinion is that it is not something the project should be worried about. But like I said, do not take that as an official position at this point. (Also, to be clear, this is all _only_ about "Git Cola". The "git-cola" command is explicitly OK in the policy because that's how commands work). > > So that's more or less where we're at now. In my opinion, a few open > > questions are: > > > > 3. Was granting "Git LFS" the right call? I think the project is a good > > one and has worked well with the greater Git community. But I think > > the name has implied some level of "officialness". We obviously > > need to allow "git-lfs" as a name. But should the policy have said > > "you can call this LFS, and the command is git-lfs, but don't say > > 'Git LFS'". I'm not sure. > > > > One option would have been to ask "git-foo" to prefer "Foo for Git" > > instead of "Git Foo" in their branding (it's too late now for "Git > > LFS", so this is a hypothetical question for future requests now). > > In my (biased) opinion, granting "Git LFS" was the right call. > > As long as the project is clearly a separate, but primarily Git-centric, > project then it seems like the right approach to allow "Git Foo" for > open source projects that contribute positively to the Git ecosystem. Yes, I have to admit that being a good citizen of the ecosystem counts for a lot in my book. But it's often helpful to make these decisions early on in the project's life (because name changes are awkward later on), and we have to just guess at how things will play out. Git Cola is again easier there because of the history. > Lastly, due to time constraints, the Git Cola logo is a tweaked version > of the Git logo, which may convey a level of "officialness" that might > be unwanted. We can work on a replacement if desired. > > Part of keeping the logo/visual identity close to core Git is because > the tool was always meant to be strongly tied to Git's unique features. > It's probably the same reason why the git-lfs branding uses similar > orange/red palettes -- to convey cohesiveness. I would prefer to keep > the visual identity as-is (including the logo). > > Can we continue to use the derivative logo for the time being until a > replacement is produced? Alternatively, can we keep the logo as-is? I don't think this is a question we've ever really considered before. I had to actually dig a little to find any use of the logo, which doesn't seem to be on most of your screenshots. :) For reference, this is the one I found: https://github.com/git-cola/git-cola/blob/master/share/git-cola/icons/git-cola.svg I do think that's much more ambiguous than just the name when it comes to potentially confusing endorsement. If a random proprietary GUI client had a logo like that, I think we'd probably ask them to change it. But I have to admit that given the general good history of git-cola,
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Sun, Sep 16, 2018 at 08:39:03AM +0200, Duy Nguyen wrote: > On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote: > > * jn/gc-auto (2018-07-17) 3 commits > > - gc: do not return error for prior errors in daemonized mode > > - gc: exit with status 128 on failure > > - gc: improve handling of errors reading gc.log > > > > "gc --auto" ended up calling exit(-1) upon error, which has been > > corrected to use exit(1). Also the error reporting behaviour when > > daemonized has been updated to exit with zero status when stopping > > due to a previously discovered error (which implies there is no > > point running gc to improve the situation); we used to exit with > > failure in such a case. > > > > What's the donness of this one? > > cf. <20180717201348.gd26...@sigill.intra.peff.net> > > This topic has stayed in 'pu' for a long time. I thought it was > concluded that this was a good change? Jeff, Jonathan? I read over the thread again. I don't think I actually have any complaints about the patches as-is. There was some discussion from Junio and Ævar about the third one. I don't have a strong opinion. My experience has been that "gc --auto" is garbage anyway on the server side, but I think Ævar's experience is that it's reasonable for small to medium sites (which seems plausible to me). The message-id quoted there is my "this looks good". I mentioned a few possible nits, but I think it would be OK with or without them addressed. -Peff
Re: Question - no space in smtp-server-option
On Mon, Sep 17, 2018 at 03:27:21AM +0200, Chris Coutinho wrote: > On Sep-16-18, Jonathan Nieder wrote: >> Chris Coutinho wrote: >>> Currently my gitconfig contains the following line: >>> >>> sendemail.smtpserveroption=-a >>> >>> Whereas, the following results in an 'account' not found error: >>> >>> sendemail.smtpserveroption=-a >> >> Do you mean that your ~/.gitconfig literally contains that exact line? [...] > Yes that's the exact line in my gitconfig file, which correctly mails using > the non-default account I'm after - I'm assuming you're noticing the lack of > camelCase? To be honest, that came from zsh autosuggestions, which are all > lower-case for some reason. No, case shouldn't matter. I'm noticing the it looks like foo.bar=baz instead of [foo] bar = baz (i.e. it seems to be some syntax other than ini syntax). E.g. I tried echo a.b=c >test.config git config -f test.config -l and get fatal: bad config line 1 in file test.config Thanks, Jonathan
[Bug] Pathspec matching breaks the add command
The following: git add -u :\(glob,attr:-someAttr\):src/** Produces an error that, according to the source code, should never be visible to the user. This attribute/pathspec *should* be supported according to the documentation provided by git: fatal: BUG:builtin/add.c:498: unsupported magic 40 It looks like the documentation claims more features than the source code supports, perhaps incorrectly because I think you shouldn't be restricted to a set of attributes, and the source code doesn't properly do its job anyways and never handles this scenario. This should be fixed, if I have any time I'll look into what it would take to submit a patch, but I don't have the time for this right now.
Re: Question - no space in smtp-server-option
On Sep-16-18, Jonathan Nieder wrote: Hi, Chris Coutinho wrote: Currently my gitconfig contains the following line: sendemail.smtpserveroption=-a Whereas, the following results in an 'account' not found error: sendemail.smtpserveroption=-a Do you mean that your ~/.gitconfig literally contains that exact line? I would be surprised to hear that syntax works --- see [1] for the syntax I would expect to work. If you have more details, that would help. Thanks, Jonathan [1] https://www.kernel.org/pub/software/scm/git/docs/git-config.html Yes that's the exact line in my gitconfig file, which correctly mails using the non-default account I'm after - I'm assuming you're noticing the lack of camelCase? To be honest, that came from zsh autosuggestions, which are all lower-case for some reason. My question is just regarding the syntax of the smtp server option, namely about the (lack of a) space signature.asc Description: PGP signature
Re: Question - no space in smtp-server-option
Hi, Chris Coutinho wrote: > Currently my gitconfig contains the following line: > > sendemail.smtpserveroption=-a > > Whereas, the following results in an 'account' not found error: > > sendemail.smtpserveroption=-a Do you mean that your ~/.gitconfig literally contains that exact line? I would be surprised to hear that syntax works --- see [1] for the syntax I would expect to work. If you have more details, that would help. Thanks, Jonathan [1] https://www.kernel.org/pub/software/scm/git/docs/git-config.html
Question - no space in smtp-server-option
Hello Git community, To send a formatted git patch as an email using git I use `git send-email`. Using another email address than my default one requires the 'smtp-server-option' to be set, and currently this flag doesn't care much for spaces. Is this desired? Currently my gitconfig contains the following line: sendemail.smtpserveroption=-a Whereas, the following results in an 'account' not found error: sendemail.smtpserveroption=-a Further, the full account flag (--account) is not recognized by `send-email`. Could someone expand a bit on the reasoning behind this? Regards, Chris signature.asc Description: PGP signature
Re: Git for games working group
Hi, On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote: > Taylor Blau wrote: >> Right, though this still subjects the remote copy to all of the >> difficulty of packing large objects (though Christian's work to support >> other object database implementations would go a long way to help this). > > Ah, interesting -- I didn't realize this step was part of the > bottleneck. I presumed git didn't do much more than perhaps gzip'ing > binary files when it packed them up. Or do you mean the growing cost > of storing the objects locally as you work? Perhaps that could be > solved by allowing the client more control (ie. delete the oldest > blobs that exist on the server). John, I believe you are correct. Taylor, can you elaborate about what packing overhead you are referring to? One thing I would like to see in the long run to help Git cope with very large files is adding something similar to bup's "bupsplit" to the packfile format (or even better, to the actual object format, so that it affects object names). In other words, using a rolling hash to decide where to split a blob and use a tree-like structure so that (1) common portions between files can deduplicated and (2) portions can be hashed in parallel. I haven't heard of these things being the bottleneck for anyone in practice today, though. Thanks, Jonathan
Re: Git for games working group
Thanks for all the thoughts so far -- I'm going to try to collate some of my responses to avoid this getting too lengthy. ## Regarding Merging / Diffing A couple of folks have suggested that we could improve merging / diffing of binary files in general. I think this is useful, but can only ever result in minor improvements, for the following reasons: 1. Game developers use an incredible amount of proprietary file formats: Maya, Houdini, Photoshop, Wwise, Unreal UAssets, etc. At the end of the day, it's fairly unlikely that we can build visual merge tools for these asset types without an enormous amount of corporate support. 2. Merging doesn't have a meaning for many types of files. I think git has trained us that everything is merge-able, but that's not always the case. If you gave an audio designer two voice-over audio files and asked them to merge them, they'd give you a pretty strange look. You have to re-record it from scratch. Content files can be highly intertwined and highly subjective: as a textual metaphor, every line of content conflicts with every other line. Even if you had a perfect merge tool, it just doesn't make much sense to try to merge changes, unless it's an incredibly simple change. ## Regarding File Locking: File locking works well enough in Perforce, but there are a couple of issues I've found using file locking in LFS or in Gitolite (hadn't seen this before, thanks!). 1. File Locking is an 'active' system. File Locking adds extra operations that must be taken, both before writing to a file and then after finishing your changes. Artists either must drop down to a terminal (unlikely), or we must integrate our file-locking system with existing artist tools (a large amount of work). Either way it adds a lot of extra grunt-work. Imagine having to manually mark which files you modify rather than just using git status. One of git's biggest benefit is removing this type of manual labor. 2. File Locking doesn't extend well across branches. Acquiring a lock usually blocks modifications to this file across all branches. This cuts off basic branching models and features (like having release branches) that are large part of why git is so successful. 3. It's not entirely sound. Developer A can modify 'binary.bin', and push the changes to master. Developer B, who is behind master by a couple of days, can then unknowingly acquire the lock and make further changes ignoring A's new commit. When B attempts to push, they will get conflicts. If you look closely, this is a symptom of issue 2: locking doesn't understand branches. ## "Implicit" Locking Instead, I think it's better to think about how we can use the structure of the git graph to solve the issue. Imagine the following pre-commit hook for a developer attempting to commit 'binary.bin': If there exists any commit binary.bin on a different branch that is not integrated into this branch, block the commit. In this case, making a commit with a file blocks others from touching it, until they pull in that commit. To make the parallel, making a commit acquires a 'lock' on the file, but there's no release. The only requirement is that you always modify the latest version of the file. This has issues of its own, and it's a simplification of the system I have in mind. It means Developer A needs to have information about the commit graph local to Developer B's machine (but notably not the files). However I think it is a better starting place for thinking about these sorts of systems. The locks fall implicitly from the commit graph structure, so it plays well with all of your normal git commands. You can branch, cherry-pick, rebase, etc without any extra support or aliases. I'll write up something a bit more detailed in a bit. - JA On Sun, Sep 16, 2018 at 7:55 AM Ævar Arnfjörð Bjarmason wrote: > > > On Sat, Sep 15 2018, Taylor Blau wrote: > > > On Fri, Sep 14, 2018 at 02:09:12PM -0700, John Austin wrote: > >> I've been working myself on strategies for handling binary conflicts, > >> and particularly how to do it in a git-friendly way (ie. avoiding as > >> much centralization as possible and playing into the commit/branching > >> model of git). > > > > Git LFS handles conflict resolution and merging over binary files with > > two primary mechanisms: (1) file locking, and (2) use of a merge-tool. > > > > 1. is the most "non-Git-friendly" solution, since it requires the use > > of a centralized Git LFS server (to be run alongside your remote > > repository) and that every clone phones home to make sure that they > > are OK to acquire a lock. > > > > The workflow that we expect is that users will run 'git lfs lock > > /path/to/file' any time they want to make a change to an > > unmeregeable file, and that this call first checks to make sure > > that they are the only person who would hold the lock. > > > > We also periodically "sync" the state of locks locally with those > > on the remote, namely
New Inquiry of your products..
Dear Supplier, We wish to make some purchase from your company.We need assurance that good quality of this items would be delivered to us after you receive our order.Please get back to us with the following information's. 1. Price list.. 2. Payment terms. 3. Specified delivery date assuming from the Date of Order Awaiting your reply ASAP. Best regards, Mrs Natalie Berly Petersen Matex Trading GmbH Hamburg, Germany Schloßstrasse 8f 22041 Hamburg Germany Email: hkberl...@gmail.com Tel. (49) 1573 599 8359 Fax (49) 1573 599 8359
Re: Git for games working group
> Right, though this still subjects the remote copy to all of the > difficulty of packing large objects (though Christian's work to support > other object database implementations would go a long way to help this). Ah, interesting -- I didn't realize this step was part of the bottleneck. I presumed git didn't do much more than perhaps gzip'ing binary files when it packed them up. Or do you mean the growing cost of storing the objects locally as you work? Perhaps that could be solved by allowing the client more control (ie. delete the oldest blobs that exist on the server).
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Sun, Sep 16 2018, Duy Nguyen wrote: > On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote: >> * jn/gc-auto (2018-07-17) 3 commits >> - gc: do not return error for prior errors in daemonized mode >> - gc: exit with status 128 on failure >> - gc: improve handling of errors reading gc.log >> >> "gc --auto" ended up calling exit(-1) upon error, which has been >> corrected to use exit(1). Also the error reporting behaviour when >> daemonized has been updated to exit with zero status when stopping >> due to a previously discovered error (which implies there is no >> point running gc to improve the situation); we used to exit with >> failure in such a case. >> >> What's the donness of this one? >> cf. <20180717201348.gd26...@sigill.intra.peff.net> > > This topic has stayed in 'pu' for a long time. I thought it was > concluded that this was a good change? Jeff, Jonathan? There's still outstanding feedback on it, including my: https://public-inbox.org/git/878t69dgvx@evledraar.gmail.com/ I think it would be great to merge [12]/3 down, and have a re-submission of 3/3 stand-alone, once that's merged down, so we can untangle obviously correct bugfixes ([12]/3) with meaningful changes in exit code behavior (3/3).
Re: Git for games working group
On Sat, Sep 15 2018, Taylor Blau wrote:
> On Fri, Sep 14, 2018 at 02:09:12PM -0700, John Austin wrote:
>> I've been working myself on strategies for handling binary conflicts,
>> and particularly how to do it in a git-friendly way (ie. avoiding as
>> much centralization as possible and playing into the commit/branching
>> model of git).
>
> Git LFS handles conflict resolution and merging over binary files with
> two primary mechanisms: (1) file locking, and (2) use of a merge-tool.
>
> 1. is the most "non-Git-friendly" solution, since it requires the use
> of a centralized Git LFS server (to be run alongside your remote
> repository) and that every clone phones home to make sure that they
> are OK to acquire a lock.
>
> The workflow that we expect is that users will run 'git lfs lock
> /path/to/file' any time they want to make a change to an
> unmeregeable file, and that this call first checks to make sure
> that they are the only person who would hold the lock.
>
> We also periodically "sync" the state of locks locally with those
> on the remote, namely during the post-merge, post-commit, and
> post-checkout hook(s).
>
> Users are expected to perform the 'git lfs unlock /path/to/file'
> anytime they "merge" their changes back into master, but the
> thought is that servers could be taught to automatically do this
> upon the remote detecting the merge.
>
> 2. is a more it-friendly approach, i.e., that the 'git mergetool'
> builtin does work with files tracked under Git LFS, i.e., that both
> sides of the merge are filtered so that the mergetool can resolve
> the changes in the large files instead of the textual pointers.
>
>
>> I've got to a loose design that I like, but it'd be good to get some
>> feedback, as well as hearing what other game devs would want in a
>> binary conflict system.
>
> Please do share, and I would be happy to provide feedback (and make
> proposals to integrate favorable parts of your ideas into Git LFS).
All of this is obviously correct as far as git-lfs goes. Just to use
this as a jump-off comment on the topic of file locking and to frame
this discussion more generally.
It's true that a tool like git-lfs "requires the use of a centralized
[...] server" for file locking, but it's not the case that a feature
like file locking requires a centralized authority.
In particular, git-lfs unlike git-annex (which preceded it) does the
opposite of (to quote John upthread) "avoid[...] as much centralization
as possible", it *is* explicitly a centralized large file solution, not
a distributed one, as opposed to git-annex.
That's not a critique of git-lfs or the centralized method, or a
recommendation for decentralization in this context, but we already have
a similar distributed solution in the form of git-annex, it's just a hop
skip and a jump away from changing "who has the file" to "who has the
lock".
So how does that work? In the centralized case like
git-lfs/cvs/p4/whatever you have some "lock/unlock" command, and it
locks a file on a central server, locking is usually a a [locked?, who]
state of "is it locked" and "who locked it?". Usually this is also
followed-up on the client-side by checking those files out without the
"w" flag.
In the hypothetical git-annex-like case (simplifying a bit for the
purposes this explanation), for every FILE in your tree you have a
corresponding FILE.lock file, but it's not a boolean, but a log of who's
asked for locks, i.e. lines of:
E.g.:
$ cat Makefile.lock
my-random-per-repo-id 2018-09-15 1 ava...@gmail.com "refactoring all
Makefiles"
my-random-per-repo-id 2018-09-16 0 ava...@gmail.com "done!"
This log is append-only, when clients encounter conflicts there's a
merge driver to ensure that all updates are kept.
You can then enact a policy saying you care or don't care about updates
from certain sources, or ignore locks older than so-and-so.
None of this is stuff I'd really recommend. It's just instructive to
point out that if someone wants a distributed locking solution for git,
it pretty much already exists, you can even (ab)use git-annex for it
today with a tiny hack on top.
I.e. each time you want to lock a file called Makefile just:
echo We created a lock for this >Makefile.lock &&
git annex add Makefile.lock &&
git annex sync
And to release the lock:
git annex rm Makefile.lock &&
git annex sync
Then you and others using this just mentally pretend (or setup aliases)
that the following mapping exists:
git annex get && git annex sync ==> git lockit
git annex rm && git annex sync ==> git unlockit
And that stuff like "git annex whereis" (designed to list "who has the
files") means "git annex who-has-locks".
Then you'd change the post-{checkout,merge} hooks to list the locks
"tracked annex files", chmod -w appropriately, and voila, a distributed
locking solution for git built on top of an
[no subject]
-- join the Illuminati secret brotherhood and get $3,000,000.00
[no subject]
-- join the Illuminati secret brotherhood and get $3,000,000.00
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote: > * bc/hash-independent-tests (2018-09-13) 12 commits > - t5318: use test_oid for HASH_LEN > - t1407: make hash size independent > - t1406: make hash-size independent > - t1405: make hash size independent > - t1400: switch hard-coded object ID to variable > - t1006: make hash size independent > - t0064: make hash size independent > - t0027: make hash size independent Could you drop this particular patch (the t0027 fix)? I found an issue with it that I'd like to address, and it would be easier for me to just send a completely fixed version in the future since it doesn't have any dependencies with the rest of the series. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
I NEED YOUR URGENT ASSISTANCE
-- Hi friend I am a banker in ADB BANK. I want to transfer an abandoned sum of USD15.6Million to your Bank account. 40/percent will be your share. No risk involved but keeps it as secret. Contact me for more details. Please reply me through my alternative email id only (salif.musa...@gmail.com) for confidential reasons. Yours Dr Salif Musa
Re: Git trademark status and policy
Hi Peff, On Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote: > > - Commands like "git-foo" (so you run "git foo") are generally OK. > This is Git's well-known extension mechanism, so it doesn't really > imply endorsement (on the other hand, you do not get to complain if > you choose too generic a name and conflict with somebody else's use > of the same git-foo name). > > - When "git-foo" exists, we've approved "Git Foo" as a matching > project name, but we haven't decided on a general rule to cover this > case. The only example here is "Git LFS". The "Git Cola" project[1][2] provides two fully-featured Git porcelains, "git-cola" and "git-dag". The DAG tool is never referred to as a separate project, so shouldn't be a concern trademark wise. The project dates back to 2007, while the "Git Cola" name dates back to 2008. FTR, the name "Cola" is also a shout-out to Linux (comp.os.linux.announce). Can we continue to use the name "Git Cola" going forward? > So that's more or less where we're at now. In my opinion, a few open > questions are: > > 3. Was granting "Git LFS" the right call? I think the project is a good > one and has worked well with the greater Git community. But I think > the name has implied some level of "officialness". We obviously > need to allow "git-lfs" as a name. But should the policy have said > "you can call this LFS, and the command is git-lfs, but don't say > 'Git LFS'". I'm not sure. > > One option would have been to ask "git-foo" to prefer "Foo for Git" > instead of "Git Foo" in their branding (it's too late now for "Git > LFS", so this is a hypothetical question for future requests now). > > -Peff In my (biased) opinion, granting "Git LFS" was the right call. As long as the project is clearly a separate, but primarily Git-centric, project then it seems like the right approach to allow "Git Foo" for open source projects that contribute positively to the Git ecosystem. Lastly, due to time constraints, the Git Cola logo is a tweaked version of the Git logo, which may convey a level of "officialness" that might be unwanted. We can work on a replacement if desired. Part of keeping the logo/visual identity close to core Git is because the tool was always meant to be strongly tied to Git's unique features. It's probably the same reason why the git-lfs branding uses similar orange/red palettes -- to convey cohesiveness. I would prefer to keep the visual identity as-is (including the logo). Can we continue to use the derivative logo for the time being until a replacement is produced? Alternatively, can we keep the logo as-is? cheers, [1] https://git-cola.github.io/ [2] https://github.com/git-cola/git-cola -- David
Re: Git for games working group
On Fri, Sep 14, 2018 at 02:13:28PM -0700, John Austin wrote:
> Hey Taylor,
>
> Great to have your support! I think LFS has done a great job so far
> solving the large file issue. I've been working myself on strategies
> for handling binary conflicts, and particularly how to do it in a
> git-friendly way (ie. avoiding as much centralization as possible and
> playing into the commit/branching model of git). I've got to a loose
> design that I like, but it'd be good to get some feedback, as well as
> hearing what other game devs would want in a binary conflict system.
>
> - John
Hey John, thanks for LFS, and thanks to Taylor for bringing up this topic.
Regarding file locking, the gitolite docs are insightful:
http://gitolite.com/gitolite/locking/index.html
File locking is how P4 handles binary conflicts. It's actually
conflict prevention -- the locks prevent users from stepping
on each other without needing to actually talk to each other.
(I've always believed that this is actually a social problem
(not a technical one) that is best served by better communication,
but there's no doubt that having a technical guard in place is useful
in many scenarios.)
>From the POV of using Git as a P4 replacement, the locking support in
git-lfs seems like a fine solution to prevent binary conflicts.
https://github.com/git-lfs/git-lfs/wiki/File-Locking
Are there any missing features that would help improve LFS solution?
Locking is just one aspect of binary conflicts.
In a lock-free world, another aspect is tooling around dealing
with actual conflicts. It seems like the main challenges there are
related to introspection of changes and mechanisms for combining
changes.
Combining changes is inherently file-format specific, and I suspect
that native authoring tools are best used in those scenarios.
Maybe LFS can help deal with binary conflicts by having short and sweet
ways to grab the "base", "their" and "our" versions of the conflict
files.
Example:
git lfs checkout --theirs --to theirs.wav conflict.wav
git lfs checkout --ours --to ours.wav conflict.wav
git lfs checkout --base --to base.wav conflict.wav
Then the user can use {ours,theirs,base}.wav to produce the
resolved result using their usual authoring tools.
>From the plumbing perspective, we already have the tools to
do this today, but they're not really user-friendly because
they require the user to use "git cat-file --filters --path=..."
and redirect the output to get at their changes.
Not sure if git-lfs is the right place for that kind of helper
wrapper command, but it's not a bad place for it either.
That said, none of these are user-friendly for non-Gits that
might be intimidated by a command-line.
Is there anything we could add to git-cola to help?
Being able to save the different conflicted index stages to
separately named files seems like an obvious feature that
would help users when confronted with a binary conflict.
With LFS and the ongoing work related to MVFS, shallow clone,
and partial checkout, the reasons to use P4 over Git are becoming
less and less compelling. It'd be great to polish the game asset
workflows further so that we can have a cohesive approach to
doing game asset development using Git that is easy enough for
non-technical users to use and understand.
I mention git-cola because it's a Git porcelain that already has
git-lfs support and I'm very much in favor of improving workflows
related to interacting with LFS, large files, repos, and binary content.
Are there other rough edges around (large) binary files that can be improved?
One thought that comes to mind is diffing -- I imagine that we
might want to use different diff tools depending on the file format.
Currently git-difftool uses a single tool for all files, but it seems
like being able to use different tools, based on the file type, could
be helpful. Not sure if difftool is the right place for that, but
being able to specify different tools per-file seems be useful in
that scenario.
Another avenue that could use help is documentation about suggested
workflows. Git's core documentation talks about various
large-file-centric features in isolation, but it'd be good to have a
single user-centric document (not unlike gitworkflows) to document best
practices for dealing with large files, repos, game assets, etc.
That alone would help dispel the myth that Git is unsuitable for
large repos, large files, and binary content.
--
David
[PATCH v5 3/3] t0014: Introduce an alias testing suite
Introduce a testing suite that is dedicated to aliases. For now, check only if nested aliases work and if looping aliases are detected successfully. The looping aliases check for mixed execution is there but disabled, because it is blocking the test suite for a full minute. As soon as there is a solution for loops using external commands, it should be enabled. Signed-off-by: Tim Schumacher --- Changes since v4: - Actually execute a command in the first two cases - Remove the "setup code" - Use i18ngrep to match the part of a message - Comment out the last test t/t0014-alias.sh | 40 1 file changed, 40 insertions(+) create mode 100755 t/t0014-alias.sh diff --git a/t/t0014-alias.sh b/t/t0014-alias.sh new file mode 100755 index 0..a070e645d --- /dev/null +++ b/t/t0014-alias.sh @@ -0,0 +1,40 @@ +#!/bin/sh + +test_description='git command aliasing' + +. ./test-lib.sh + +test_expect_success 'nested aliases - internal execution' ' + git config alias.nested-internal-1 nested-internal-2 && + git config alias.nested-internal-2 status && + git nested-internal-1 >output && + test_i18ngrep "^On branch " output +' + +test_expect_success 'nested aliases - mixed execution' ' + git config alias.nested-external-1 nested-external-2 && + git config alias.nested-external-2 "!git nested-external-3" && + git config alias.nested-external-3 status && + git nested-external-1 >output && + test_i18ngrep "^On branch " output +' + +test_expect_success 'looping aliases - internal execution' ' + git config alias.loop-internal-1 loop-internal-2 && + git config alias.loop-internal-2 loop-internal-3 && + git config alias.loop-internal-3 loop-internal-2 && + test_must_fail git loop-internal-1 2>output && + test_i18ngrep "^fatal: alias loop detected: expansion of" output +' + +# This test is disabled until external loops are fixed, because would block +# the test suite for a full minute. +# +#test_expect_failure 'looping aliases - mixed execution' ' +# git config alias.loop-mixed-1 loop-mixed-2 && +# git config alias.loop-mixed-2 "!git loop-mixed-1" && +# test_must_fail git loop-mixed-1 2>output && +# test_i18ngrep "^fatal: alias loop detected: expansion of" output +#' + +test_done -- 2.19.0.rc2.1.g4c98b8d69.dirty
[PATCH v5 2/3] Show the call history when an alias is looping
Just printing the command that the user entered is not particularly
helpful when trying to find the alias that causes the loop.
Print the history of substituted commands to help the user find the
offending alias. Mark the entrypoint of the loop with "<==" and the
last command (which looped back to the entrypoint) with "==>".
Signed-off-by: Tim Schumacher
---
No changes since v4.
git.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 15727c17f..a20eb4fa1 100644
--- a/git.c
+++ b/git.c
@@ -675,6 +675,7 @@ static int run_argv(int *argcp, const char ***argv)
{
int done_alias = 0;
struct string_list cmd_list = STRING_LIST_INIT_NODUP;
+ struct string_list_item *seen;
while (1) {
/*
@@ -692,9 +693,21 @@ static int run_argv(int *argcp, const char ***argv)
/* .. then try the external ones */
execv_dashed_external(*argv);
- if (unsorted_string_list_has_string(_list, *argv[0])) {
+ seen = unsorted_string_list_lookup(_list, *argv[0]);
+ if (seen) {
+ int i;
+ struct strbuf sb = STRBUF_INIT;
+ for (i = 0; i < cmd_list.nr; i++) {
+ struct string_list_item *item =
_list.items[i];
+
+ strbuf_addf(, "\n %s", item->string);
+ if (item == seen)
+ strbuf_addstr(, " <==");
+ else if (i == cmd_list.nr - 1)
+ strbuf_addstr(, " ==>");
+ }
die(_("alias loop detected: expansion of '%s' does"
- " not terminate"), cmd_list.items[0].string);
+ " not terminate:%s"), cmd_list.items[0].string,
sb.buf);
}
string_list_append(_list, *argv[0]);
--
2.19.0.rc2.1.g4c98b8d69.dirty
[PATCH v5 1/3] Add support for nested aliases
Aliases can only contain non-alias git commands and their
arguments, not other user-defined aliases. Resolving further
(nested) aliases is prevented by breaking the loop after the
first alias was processed. Git then fails with a command-not-found
error.
Allow resolving nested aliases by not breaking the loop in
run_argv() after the first alias was processed. Instead, continue
the loop until `handle_alias()` fails, which means that there are
no further aliases that can be processed. Prevent looping aliases
by storing substituted commands in `cmd_list` and checking if
a command has been substituted previously.
While we're at it, fix a styling issue just below the added code.
Signed-off-by: Tim Schumacher
---
Changes since v3:
- Print the command that the user entered instead of the command
which caused the loop (and a nicer, more explanatory error message)
- Use unsorted_string_list_has_string() instead of the sorted version
- Fix a code style issue just below the modified code
- done_alias is a simple boolean again (instead of a counter)
Changes since v4: None.
git.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/git.c b/git.c
index c27c38738..15727c17f 100644
--- a/git.c
+++ b/git.c
@@ -674,6 +674,7 @@ static void execv_dashed_external(const char **argv)
static int run_argv(int *argcp, const char ***argv)
{
int done_alias = 0;
+ struct string_list cmd_list = STRING_LIST_INIT_NODUP;
while (1) {
/*
@@ -691,17 +692,25 @@ static int run_argv(int *argcp, const char ***argv)
/* .. then try the external ones */
execv_dashed_external(*argv);
- /* It could be an alias -- this works around the insanity
+ if (unsorted_string_list_has_string(_list, *argv[0])) {
+ die(_("alias loop detected: expansion of '%s' does"
+ " not terminate"), cmd_list.items[0].string);
+ }
+
+ string_list_append(_list, *argv[0]);
+
+ /*
+* It could be an alias -- this works around the insanity
* of overriding "git log" with "git show" by having
* alias.log = show
*/
- if (done_alias)
- break;
if (!handle_alias(argcp, argv))
break;
done_alias = 1;
}
+ string_list_clear(_list, 0);
+
return done_alias;
}
--
2.19.0.rc2.1.g4c98b8d69.dirty
Re: [RFC PATCH v4 1/3] Add support for nested aliases
On 08.09.18 15:28, Duy Nguyen wrote: On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote: + /* +* It could be an alias -- this works around the insanity * of overriding "git log" with "git show" by having * alias.log = show */ I think this comment block is about the next two lines you just deleted. So delete it to instead of fixing style. I think that comment is talking about the code that is handing the alias, so it still would be valid. The check might have peen placed in between to keep it logically grouped. - if (done_alias) - break; if (!handle_alias(argcp, argv)) break; done_alias = 1; }
Re: [RFC PATCH v4 3/3] t0014: Introduce alias testing suite
On Fri, Sep 14, 2018 at 7:12 PM Tim Schumacher wrote: > This is the first multi-patch series that I submitted, so I'm unsure if I > should send the updated patch only or if I should send the complete series > again as v5. Any pointers to what the correct procedure for this case is would > be appreciated. Re-send the entire series as v5. That makes it easier on reviewers (who don't need to go searching through the mailing list archive to get a full picture) and reduces Junio's workload since it's usually easier for him to re-queue a series wholesale than having to slice-and-dice some replacement patches into what was already queued.
Re: [PATCH] read-cache.c: fix a sparse warning
On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones wrote: > At one time, the POSIX standard required the type used to represent > a thread handle (pthread_t) be an arithmetic type. This is no longer > the case, probably because different platforms used to regularly > ignore that requirement. For example, on cygwin a pthread_t is a > pointer to a structure (a quite common choice), whereas on Linux it > is defined as an 'unsigned long int'. > > On cygwin, but not on Linux, 'sparse' currently complains about an > initialiser used on a 'struct load_index_extensions' variable, whose > first field may be a pthread handle (if not compiled with NO_PTHREADS > set). > > In order to fix the warning, move the (conditional) pthread field to > the end of the struct and change the initialiser to use a NULL, since > the new (unconditional) first field is a pointer type. > > Signed-off-by: Ramsay Jones > --- > If you need to re-roll your 'bp/read-cache-parallel' branch, could you > please squash this into the relevant patch (commit a090af334, > "read-cache: load cache extensions on a worker thread", 2018-09-12). The information contained in this commit message is so useful that it might make sense to plop this patch at the end of the series rather than merely squashing it in. (Or, if it is squashed, include the above explanation in the commit message of the appropriate patch.)
Re: [Bug report] Git incorrectly selects language in macos
On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote: > Looks like the issue appeared after updating git from brew. > > A quick search revealed that brew changed how it builds git recently. > I think, it just didn't include i18n by default before, so I never > noticed this. > > Anybody here familiar enough with the build process and dependencies > of git to pinpoint what exactly is causing this and how to fix it?... This problem is not specific to Git. Earlier in the thread, Ævar asked[1] if the problem also occurs with other command-line programs, and indeed it does. For instance, I tried with 'wget' installed via brew, and it exhibits the same odd behavior. Ævar suggested that there might be some magic special-casing English, which makes me wonder if brew builds such magic into gettext(?) or if the magic is part of MacOS itself. [1]: https://public-inbox.org/git/87a7ojlp31@evledraar.gmail.com/
Re: [PATCH v2 2/2] commit-graph verify: add progress output
On Fri, Sep 7, 2018 at 8:30 PM Ævar Arnfjörð Bjarmason wrote:
> @@ -989,11 +990,14 @@ int verify_commit_graph(struct repository *r, struct
> commit_graph *g)
> if (verify_commit_graph_error & ~VERIFY_COMMIT_GRAPH_ERROR_HASH)
> return verify_commit_graph_error;
>
> + progress = start_progress("Verifying commits in commit graph",
_()
> + g->num_commits);
--
Duy
ATENÇÃO
ATENÇÃO; Sua caixa de correio excedeu o limite de armazenamento, que é de 5 GB como definido pelo administrador, que está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa de correio, envie os seguintes dados abaixo: nome: Nome de usuário: senha: Confirme a Senha : Endereço de e-mail: Telefone: Se você não conseguir revalidar sua caixa de correio, sua caixa postal vai ser desativado! Lamentamos o inconveniente. Código de verificação: pt:p9uyba078434>2018 Correio Técnico Suporte ©2018 obrigado Administrador de Sistemas --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote: > * jn/gc-auto (2018-07-17) 3 commits > - gc: do not return error for prior errors in daemonized mode > - gc: exit with status 128 on failure > - gc: improve handling of errors reading gc.log > > "gc --auto" ended up calling exit(-1) upon error, which has been > corrected to use exit(1). Also the error reporting behaviour when > daemonized has been updated to exit with zero status when stopping > due to a previously discovered error (which implies there is no > point running gc to improve the situation); we used to exit with > failure in such a case. > > What's the donness of this one? > cf. <20180717201348.gd26...@sigill.intra.peff.net> This topic has stayed in 'pu' for a long time. I thought it was concluded that this was a good change? Jeff, Jonathan? -- Duy
[PATCH v2 0/1] Make 'git commit' not accidentally lose staged content
This is about mixing "git add -p" and "git commit -a" (or "git commit ") where you may accidentally lose staged changes. After the discussion with Jonathan, I'm going with a bit different approach than v1, this behavior now becomes default, and if the user wants the old behavior back, they can use --clobber-index. Another change is "git commit " is covered as well, as pointed out by Jacob. I will need to add some test cases of course, if this direction is still promising. One thing I'm not sure about is whether want to deliberately clobber the index often, then perhaps we should add a config key to bring the old behavior back. Nguyễn Thái Ngọc Duy (1): commit: do not clobber the index Documentation/git-commit.txt | 11 +++- builtin/commit.c | 105 --- cache.h | 1 + read-cache.c | 11 t/t2201-add-update-typechange.sh | 2 +- t/t4015-diff-whitespace.sh | 2 +- t/t7102-reset.sh | 2 +- t/t7500-commit.sh| 2 +- t/t7502-commit.sh| 4 +- t/t9350-fast-export.sh | 2 +- 10 files changed, 126 insertions(+), 16 deletions(-) -- 2.19.0.rc0.337.ge906d732e7
[PATCH v2 1/1] commit: do not clobber the index
"git commit" can be used in two different workflows:
- the user never bothers with "git add" and uses "git commit" for
both adding content to the index and committing it
- the user uses "git add" to carefully prepare what they want to
commit, and "git commit" creates a new commit out of the current
index. In this case "git commit" does not modify the index at all.
The user could switch between the two workflows of course, and
mistakes can happen that lead to content loss. Imagine the user has
prepared the index with 'git add -p' (second workflow), which makes
the index content different from both HEAD and worktree. If they
accidentally do "git commit -a" (first workflow) after that, all the
preparation is gone because "git commit" clobbers the index.
Prevent this by checking the staged content when runnning "commit -a"
or "commit ". If the staged content is different from both HEAD
and the worktree version, abort the commit. The user can still
override this by giving "--clobber-index" option.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-commit.txt | 11 +++-
builtin/commit.c | 105 ---
cache.h | 1 +
read-cache.c | 11
t/t2201-add-update-typechange.sh | 2 +-
t/t4015-diff-whitespace.sh | 2 +-
t/t7102-reset.sh | 2 +-
t/t7500-commit.sh| 2 +-
t/t7502-commit.sh| 4 +-
t/t9350-fast-export.sh | 2 +-
10 files changed, 126 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index f970a43422..2d128527ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -31,8 +31,9 @@ The content to be added can be specified in several ways:
3. by listing files as arguments to the 'commit' command
(without --interactive or --patch switch), in which
- case the commit will ignore changes staged in the index, and instead
- record the current content of the listed files (which must already
+ case the commit will ignore changes staged in the index if
+ --clobber-index is specified, and instead record the current
+ content of the listed files (which must already
be known to Git);
4. by using the -a switch with the 'commit' command to automatically
@@ -274,6 +275,12 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
already been staged. If used together with `--allow-empty`
paths are also not required, and an empty commit will be created.
+--clobber-index::
+ By default 'git commit' will not update the index if
+ non-conflicted staged content of a path is different from both
+ HEAD and the working tree. This option skips this check and
+ makes 'git commit' ignore content changes in the index.
+
-u[]::
--untracked-files[=]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index 0d9828e29e..a179b8a9e7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -101,6 +101,7 @@ static int all, also, interactive, patch_interactive, only,
amend, signoff;
static int edit_flag = -1; /* unspecified */
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static int config_commit_verbose = -1; /* unspecified */
+static int clobber_index;
static int no_post_rewrite, allow_empty_message;
static char *untracked_files_arg, *force_date, *ignore_submodule_arg,
*ignored_arg;
static char *sign_commit;
@@ -263,11 +264,78 @@ static int list_paths(struct string_list *list, const
char *with_tree,
return ret;
}
-static void add_remove_files(struct string_list *list)
+static void mark_staged_paths_cb(struct diff_queue_struct *q,
+struct diff_options *options,
+void *data)
+{
+ struct index_state *istate = data;
+ int i;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p;
+ int pos;
+
+ p = q->queue[i];
+
+ switch (p->status) {
+ case DIFF_STATUS_ADDED:
+ break;
+
+ case DIFF_STATUS_MODIFIED:
+ /*
+* _MODIFIED could be either because of content or
+* mode change. Ignore mode change.
+*/
+ if (oidcmp(>one->oid, >two->oid))
+ break;
+ continue;
+
+ default:
+ continue;
+ }
+
+ pos = index_name_pos(istate, p->two->path,
+strlen(p->two->path));
+ if (pos < 0)
+ BUG("entry '%s' => '%s' status '%c' not found in the
index",
+ p->one->path ? p->one->path : "(empty)",
+ p->two->path ?
Re: Feature request: be able to pass arguments to difftool command
On Wed, Aug 29, 2018 at 09:18:38AM +0200, H.Merijn Brand wrote:
> On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano
> wrote:
>
> > "H.Merijn Brand" writes:
> >
> > > So, my wish would be to have an option, possibly using -- to pass
> > > additional command line arguments to git difftool, so that
> > >
> > > $ git difftool $commit~1..$commit -- -m -v2
> > >
> > > would pass the arguments after -- transparantly to ccdiff (in my case)
> >
> > At the syntax level passing any option after "--" would be a no
> > starter, as I would imagine that "git difftool $revs -- $paths"
> > should still be supported.
> >
> > At the concept level, however, I can see why such a feature would be
> > useful. Perhaps
> >
> > $ git difftool --backend-option=-m --backend-option=-v2 HEAD
> > $ git mergetool --backend-option=--foo
>
> This would mean I can just pass remaining arguments, like this?
>
> --8<--- ~/bin/git-ccdiff
> #!/usr/bin/env perl
> use 5.18.3;
> use warnings;
>
> my $commit;
>
> @ARGV && $ARGV[0] !~ m/^-/ and $commit = shift;
>
> my @git = qw( git difftool );
> defined $commit and push @git, "$commit~1..$commit";
> system @git, @ARGV;
> -->8---
>
> > with appropriate way(s) [*1*] to make it easier to type (and
> > implement) would be an acceptable avenue to pursue, I wonder?
>
> I like it, as long as they are all separate options in the backend and
> not available in one single variable that needs to be split
>
> I can envision a configure variable like
>
> backends.options.separator = U+2063
>
> so the backend can safely split on that itself. But I also see this as
> overly complex en over-engineering
Personally, I think it'd be better to keep the tool simple.
While I do see the utility, it would be just as easy to configure a 2nd
and 3rd variant of the same difftool and use those as needed instead.
"git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
nothing stopping the user from creating aliases to shorten it further.
We also already have, "git difftool -x / --extcmd"
for specifying a full-on external diff command.
> git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool
For example, this seems simpler as:
git difftool -x 'ccdiff -v2 -m'
We already have two mechanisms for controlling the inner command that's
launched by difftool. IMO we don't need more.
My primary concerns with --backend-opts are as follows:
1. If we add a mechansim for passing -X/--backend-opts, then we
need to specify a new variable that users will need to be aware
of when creating custom commands. (sorry for stating the obvious)
2. All of the built-in commands would need to change to honor that
variable.
3. The documentation becomes more complex because someone that wants
to configure a bog-standard custom external tool now needs to
be aware of this extra external source of arguments.
#1 and #2 are primarily implementation concerns, but #3 suggests
to me that it's over-complicating things.
Furthermore, #2 is not really that simple.
What would the sciplet look like?
diff_cmd () {
"$merge_tool_path" $EXTRA_ARGS ...
}
That implies that we would need to shell quote stuff when
constructing $EXTRA_ARGS internally if we were to support multiple -X
arguments. That just made it a bit more complex.
IMO we should be working to simpliify, not make things more complex for
rare use cases. There's no reason the user can't just do:
V=2 git difftool
V=3 git difftool
... and let the inner script check for $V (or any other) variable.
While environment variables aren't great, this does seem like the right
place to use them.
Another option -- we already eval the configured command, so if the user
includes a variable ($ARGS) in their custom configuration then they can
specify extra flags today without needing to change the tool. ex:
[difftool "ccdiff"]
cmd = ccdiff $ARGS \"$LOCAL\" \"$REMOTE\"
ARGS='-v2 -m' git difftool HEAD~1..HEAD
Are these alternatives short and simple enough?
--
David
