> Perhaps "-v" should have been the default all along. I do not use "git
> remote" myself, so I don't know if "-v" is what most people use. But
> changing the output of "git remote" now is probably a bad thing (I
> expect some people may depend on parsing it to get the list of remotes;
> they shou
> I often write `git remote list` before finaly using `git remote -v` but
> it isn't intuitive.
>
> I am proposing to add `git remote list` as a shortcut for `git remote -v`
I suffer from the same problem. I think your proposal is a logical and
nice idea.
Philippe
--
To unsubscribe from this list
> Felipe Contreras wrote:
>> == git update ==
>>
>> Another proposed solution is to have a new command: `git update`. This
>> command would be similar to `git pull --ff-only` by default, but it
>> could be configured to do merges instead, and when doing so in reverse.
>
> And here it is:
>
> https:
> scenario:
> - edit some tracked files; do not add them to the index
> - "git config rebase.autostash true"
> - "git rebase -i HEAD~3" (an autostash will be created)
> - delete the entire buffer and save/exit the editor - this will abort the
> rebase
>
> poof, the autostash is gone (it is not re
>> I'm sorry that my words aren't clear enough for you to infer the point
>> I'm trying to make. Let's try something simpler: what I was saying is
>> that bad behavior will get you into trouble when contributing (and
>> thus it's important to behave nicely), where Felipe usualy says bad
>> behavior
>> My point was more that it's very hard to produce high quality commits
>> without social interaction with others explaining what you missed,
>> stuffs you overlooked, etc.
>
> You are overgeneralizing. You are assuming that it's easier for
> everybody to interact with humans rather than the Tao
>> I have had patches and contributions rejected in the past, sometimes
>> rudely. Same has happened to many others, if you contribute long
>> enough, it is pretty much guaranteed that it will happen to you.
>> Maintainer is wrong, or you are wrong, or someone is just having a bad
>> day.
>
> This
> Basically you have to write in a manner "if a seedy stranger gave me
> that code on a street corner, I would have no problem checking it in".
> In practice, the shortcuts offering themselves through civil behavior
> and mutual trust get a lot more work done.
My point was more that it's very hard
>> Thanks for the explanation. I think it underlines well the A)
>> technical issues (quality commits) and the B) social issues (ability
>> to communicate in a friendly way & respond constructively), which we
>> discovered are both *essential* for contributing to git.
>
> I'm not entirely convinced
>>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>>> some tools in the core, like 'git-request-pull' (which has known bugs),
>>> and probably even 'git-pt'.
>>
>> Junio, can you comment on this? I understand this probably doesn't
>> really affect the issue at hand, but it
Nevermind, it'd be more efficient to cover this in the other main
thread started by Felipe. You can answer my questions there instead as
it'll likely benefit a wider audience.
Philippe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
> I addressed every issue reported constructively, every bug report was
> fixed, every patch reviewed and usually improved by me. I made sure
> users of older versions wouldn't be affected negatively when the marks
> file was upgraded, and I even setup automatic tests for different
> versions Bazaa
>> Yes, of course there should be a list of both positive and negative
>> tradeoffs. But I think the "overloaded" argument can be easily solved
>> by renaming one of the overloads.
>
> And renaming one of a term also has costs, especially if it is one
> that is in use in large amounts of documentat
>> I agree. The "stage area" is a very important concept in git, why not
>> talk git commands that refers to it? Then we could add flags like
>> --new-files or --deleted-files for better granularity than the current
>> --all flag.
>
> One caution: The term "stage/staged" is already a little overloa
> I think you are on the right track but the solution is not to shrug shoulders.
> We should acknowledge there are serious problems with the interface, list
> them,
> and try to fix them. One example is `git add $tracked_file` being wrong, it
> should be `git stage $tracked_file`.
I agree. The "s
> > I don't even think we need to query the user to fill out all of the
> > fields. We can prepopulate a lot of the fields (name, e-mail address,
> > etc.) from OS specific defaults that are available on most systems ---
> > specifically, the default values we would use the name and e-mail
> > add
> FWIW, I think if you made a poll and asked which color is the most
> "positive" between green and red, the vast majority of people would
> say "green". Examples could be traffic green lights vs red lights, or
> that in nature quiet & peaceful usually involves green while
> danger/action involves
> > You don't think red represent an oldness in Git? Whereas green
> > represents progress?
>
> No, I don't think that.
>
> Perhaps you think that, but if that is the case, it is based on your own
> sociocultural background. Hey, and let's not forget that supposedly 8% or so
> of all males are re
> I used to repack older part of history manually with a deeper depth,
> mark the result with the .keep bit, and then repack the whole thing
> again to have the remainder in a shallower depth. Something like:
>
> git rev-list --objects v1.5.3 |
> git pack-objects --depth=128 --delt
> fwiw this is the thread that added --depth=250
>
> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
This post is quite interesting:
http://article.gmane.org/gmane.comp.gcc.devel/94637
Philippe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
> >> * fixup! or squash! on it's own would default to fixing-up the
> >> previous commit (or result of previous step of rebase if that was a
> >> squash/fixup).
> >
> > Why would you want that? To fixup the previous commit, just use 'git
> > commit --amend'. What am I missing?
>
> In the past I've
> I'm normally an Emacs+command-line user, but I also use Eclipse or
> Netbeans on some projects.
Did you give magit a try? It's really an awesome emacs plugin, which
gives me pretty much the same control as the command line experience
without the pain. Ask me more about if if you're interested.
> Also, you are ignoring all the advantages that shell has and python does not.
Out of curiosity, can you list the advantages? From what I gathered:
- no need to install bash
- git contributors are more used to bash
- there's only one "version" of bash (no real need to handle different
versions c
> On the git-users mailing list we're trying someone to help with
> running `git push` over FTP. That person is runnig Git 1.7.9.5
> on Ubuntu 12.04.
I don't think vanilla git supports pushing over ftp.
There are plugins like https://github.com/resmo/git-ftp tho.
Philippe
--
To unsubscribe from
> At the moment the bare repository is about 4Gb in size and about 2/3rds the
> way through fetching.
That's a big repo. Lots of binary files in it?
Does git fsck run normally? Does it report a lot of dangling blogs/commits/etc?
Philippe
--
To unsubscribe from this list: send the line "unsubscri
25 matches
Mail list logo
