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:
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 should probably
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:
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 reapplied) --
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'd help
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 of that:
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 to
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 is not
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 of
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 is
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
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 Bazaar
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
address are
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 stage
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 documentation, both
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 red-green
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 red (tree
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
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 message
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.
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
21 matches
Mail list logo
