Dany nes...@gmail.com writes:
Again, I think the case where one intends to force push many branches
is certainly not as common as the case where one intends to force push
one branch, so why does git's default behavior leave the user in the
position of fscking himself over pretty badly?
I
Dany nes...@gmail.com writes:
lol, confusion abound. this message was intended to be in response to Re:
Feature request: prevent push -f from pushing all branches at once
While we're there: please, don't top-post here. Quote the part of the
message you're replying to, and reply below
Ed Hutchins e...@demeterr.com writes:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is
I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to the commit
so that analysis of the ancestry graph can be tied to the branch topics
that the original author was working from. Currently if you have a
On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins e...@demeterr.com wrote:
On the other hand
trying to figure
out the history of events from a large directed graph of commits
without any clue about
what topics first spawned each commit is actively harmful in many
cases (trying to display
a clear
I might be able to switch our corporate workflow to adding non-ff merge
commits, but the reason we moved away from using github's big red button
in the first place was to avoid the extra noise of merge-only commits.
Actually you've pointed out an inconsistency: why is it okay for merge
commits to
Ed Hutchins e...@demeterr.com writes:
I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to the commit
so that analysis of the ancestry graph can be tied to the branch topics
that the original author was working
Ed Hutchins e...@demeterr.com writes:
I might be able to switch our corporate workflow to adding non-ff merge
commits, but the reason we moved away from using github's big red button
in the first place was to avoid the extra noise of merge-only commits.
Actually you've pointed out an
Hi,
I had a pretty sucky thing happen to me today: while remote tracking a
non-master branch, I force pushed. This had the intended effect of force
pushing the branch I was working on, but also the unintended function of force
pushing all branches I wasn't on.
I'm open to anyone's thoughts
Hi Dany,
Dany wrote:
I had a pretty sucky thing happen to me today: while remote tracking
a non-master branch, I force pushed. This had the intended effect of
force pushing the branch I was working on, but also the unintended
function of force pushing all branches I wasn't on.
Yeah, I agree
[I'm sorry about breaking Cc: chain - responding via GMane web interface]
Junio C Hamano gitster at pobox.com writes:
Ed Hutchins eh at demeterr.com writes:
I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to
Hey Jonathan,
Thanks for the quick reply. I think that's a great message; I do have to say
that I wouldn't have known what the `matching` and `simple` modes are without
that message; I just had to look it up is all. It may be helpful to tell users
that `simple` is probably what they want :)
lol, confusion abound. this message was intended to be in response to Re:
Feature request: prevent push -f from pushing all branches at once
On Jul 3, 2013, at 4:52 PM, Dany nes...@gmail.com wrote:
Hey Jonathan,
Thanks for the quick reply. I think that's a great message; I do have to say
On 4 July 2013 09:46, Jakub Narebski jna...@gmail.com wrote:
Junio C Hamano gitster at pobox.com writes:
It is not just misleading but is actively wrong to recording the
name of the original branch in commits and carrying them forward via
rebase. If you want a record of what a group of commits
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is it planned, or
would it be deemed useful
On Tue, Jul 02, 2013 at 12:37:13PM -0700, Ed Hutchins wrote:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to
Ed Hutchins e...@demeterr.com writes:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example).
Hmm. I think the current thinking so
On Tue, Jul 2, 2013 at 9:37 PM, Ed Hutchins e...@demeterr.com wrote:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there
I'm not sure I follow how it could be actively harmful? I would think
the author branch
nomenclature (as opposed to just calling it branch) along with clear
documentation
that these values are just captures of the particular state the commit
was authored
from would more than assuage any potential
.nabble.com/Feature-request-fetch-prune-by-default-tp7563241p7590048.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
I use a fairly complex `git-log` command involving `--date-order` to
get an overview of my repository's status; but unfortunately,
`--date-order` seems to use the *committer* date, not the *author*
date. That means that each time I bring my topic branches up to date
by rebasing them onto the
On Mon, 27 May 2013 16:11:06 +0430, Omid Mo'menzadeh omid.mnza...@gmail.com
wrote:
Dear Tomas,
I was using your git bundler a few days ago, and it worked like a charm.
But there is a problem out there, and that is most users of your bundler
are people using an unstable internet connection. I
In my work, we have a lot of autogenerated files that need to exist so
a script will replace their contents, but tracking the contents
creates a lot of unnecessary conflicts. I would love to see an option
for a different tracking method that just makes sure a file or
directory exists. This would
On Thu, 23 May 2013 12:01:43 +, Brett Trotter wrote:
In my work, we have a lot of autogenerated files that need to exist so
a script will replace their contents, but tracking the contents
creates a lot of unnecessary conflicts. I would love to see an option
for a different tracking method
Jeff King p...@peff.net writes:
Yeah, I'm not planning to work on this, but I'd be happy to review
patches if somebody else wants to.
I am not planning to work on this, and honestly speaking I would not
be very happy to see any patch in this area.
--
To unsubscribe from this list: send the
Jeff King p...@peff.net writes:
I'd rather not invent a new language. It will either not be featureful
enough, or will end up bloated. Or both. How about something like:
[include]
exec =
case \$GIT_DIR\ in)
*/dev/*) cat ~/.config/git/dev-config ;;
On Fri, Mar 22, 2013 at 05:06:28PM -0700, Jonathan Nieder wrote:
I'd rather not invent a new language. It will either not be featureful
enough, or will end up bloated. Or both. How about something like:
[include]
exec =
case \$GIT_DIR\ in)
*/dev/*) cat
On Sat, Mar 23, 2013 at 07:15:42AM +0100, Thomas Rast wrote:
It involves a shell invocation, but it's not like we parse config in a
tight loop. Bonus points if git provides the name of the current config
file, so exec can use relative paths like:
We do, however, parse config more than
On Fri, Mar 22, 2013 at 09:56:17PM -0700, David Aguilar wrote:
On Fri, Mar 22, 2013 at 9:52 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
Hi.
Right now, when I use difftool --dir-diff, the temp dirs are creates as
e.g.:
/tmp/git-difftool.QqP8x/left
On Sat, 2013-03-23 at 12:36 +, John Keeping wrote:
What do you all think about something like the output of
git describe --always instead of the SHA-1?
I think Christoph was suggesting that it should use the revision as
specified by the user, presumably falling back to HEAD when only one
It'd be cool if I were able to override config settings at every
nested directory.
For example, I have my ~/.gitconfig that has one email address in it,
but I also have multiple repos inside ~/dev which I want to use a
different email address for. The only way to do that now is to edit
all of
Hi.
Right now, when I use difftool --dir-diff, the temp dirs are creates as
e.g.:
/tmp/git-difftool.QqP8x/left
/tmp/git-difftool.QqP8x/right
Wouldn't it be nice, if instead of left/right... the specified commit
name would be used?
e.g.
/tmp/git-difftool.QqP8x/r1.1.1
/tmp/git-difftool.QqP8x/HEAD
Hi Josh,
Josh Sharpe wrote:
For example, I have my ~/.gitconfig that has one email address in it,
but I also have multiple repos inside ~/dev which I want to use a
different email address for. The only way to do that now is to edit
all of these: ~/dev/*/.git/conf -- and there are lots of
On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote:
* Maintaining configuration per repository to record a rather simple
is more complicated than ideal. It would be easier to understand
the configuration if ~/.gitconfig could spell out the rule
explicitly:
Jeff King wrote:
On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote:
It would be easier to understand
the configuration if ~/.gitconfig could spell out the rule
explicitly:
[...]
It sounds hard to do right, especially considering use
On Fri, Mar 22, 2013 at 9:52 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
Hi.
Right now, when I use difftool --dir-diff, the temp dirs are creates as
e.g.:
/tmp/git-difftool.QqP8x/left
/tmp/git-difftool.QqP8x/right
Wouldn't it be nice, if instead of left/right... the specified
Hi Junio,
On 03/07/2013 06:33 PM, Junio C Hamano wrote:
Eric Chamberland eric.chamberl...@giref.ulaval.ca writes:
What you want is a way to compute, given a set of tags (or refs in
general) and a set of branches (or another set of refs in general),
find the ones in the former that none of the
Eric Chamberland eric.chamberl...@giref.ulaval.ca writes:
1) git tag --delete-tags-to-danglings-and-unnamed-banches
This would be able to remove all tags that refers to commits which are
on branches that are no more referenced by any branch name. This is
happening when you tag something,
On Mon, Feb 18, 2013 at 12:45 PM, Jeff King p...@peff.net wrote:
The thing that makes 2FA usable in the web browser setting is that you
authenticate only occasionally, and get a token (i.e., a cookie) from
the server that lets you have a longer session without re-authenticating.
Right,
Hi everyone,
Just would like to request a security feature to help secure peoples
github accounts more by supporting 2 factor authentication like the
yubikey more information can be found from this link
www.yubico.com/develop/ and googles 2 factor authentication. Hope it
gets implemented as
On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend townsend...@hotmail.com wrote:
Hi everyone,
Just would like to request a security feature to help secure peoples github
accounts more by supporting 2 factor authentication like the yubikey more
information can be found from this link
On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:
Just would like to request a security feature to help secure peoples github
accounts more by supporting 2 factor authentication like the yubikey more
information can be found from this link www.yubico.com/develop/ and googles
2
On Mon, Feb 18, 2013 at 3:45 PM, Jeff King p...@peff.net wrote:
On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:
Just would like to request a security feature to help secure peoples github
accounts more by supporting 2 factor authentication like the yubikey more
information can
Robert Clausecker:
I have a server that hosts a bare git repository. This git repository
contains a branch production. Whenever somebody pushes to production a
hook automatically puts a copy of the current production branch
into /var/www/foo. I could of course use pull for that but it just
a branch into an arbitrary directory. Also, it
satisfies all 4 criteria from [1] and therefore is perfect for
deployment from a bare repository.
What do you think about this feature request?
Yours, Robert Clausecker
[1]: http://sitaramc.github.com/the-list-and-irc/deploy.html
Am Dienstag, den
be used together with
--work-tree to check out a branch into an arbitrary directory. Also, it
satisfies all 4 criteria from [1] and therefore is perfect for
deployment from a bare repository.
What do you think about this feature request?
I am not Phil, but if you ask me, I think it is borderline
Junio C Hamano gits...@pobox.com writes:
I am not Phil, but if you ask me, I think it is borderline between
meh and no way we would give a short-and-sweet -i to something
like this.
I think one reason it was meh for me is that we never did an
equivalent of cvs export and svn export, primarily
There are two things git archive is missing that are needed in my use
case:
First, git archive in combination with tar won't remove unneeded files.
You have to run rm -rf before manually which brings me to the next
point; git archive can't really make incremental updates. Consider an
export that
Hi Robert,
Robert Clausecker wrote:
There are two things git archive is missing that are needed in my use
case:
First, git archive in combination with tar won't remove unneeded files.
You have to run rm -rf before manually which brings me to the next
point; git archive can't really make
That is actually a pretty interesting approach. I can use a different
index file for different deployments. How does this cooperate with bare
repositories? Aren't they supposed to have no index file at all?
Am Samstag, den 09.02.2013, 20:06 -0800 schrieb Jonathan Nieder:
My advice is to keep a
Robert Clausecker wrote:
That is actually a pretty interesting approach. I can use a different
index file for different deployments. How does this cooperate with bare
repositories? Aren't they supposed to have no index file at all?
It should work fine in a bare repo.
If you can think of a
On Mon, Feb 4, 2013 at 10:22 PM, Junio C Hamano gits...@pobox.com wrote:
Tomas Carnecky tomas.carne...@gmail.com writes:
That's what `git checkout` is for. And I would even argue that it's the
better
choice in your situation because it would delete files from /var/www/foo
which
you have
Robert Clausecker venit, vidit, dixit 03.02.2013 15:18:
Hello!
git currently has the archive command that allows to save an arbitrary
revision into a tar or zip file. Sometimes it is useful to not save this
revision into an archive but to directly put all files into an arbitrary
directory.
On Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker fuz...@gmail.com wrote:
Of course that is a possibility but it does not not feel right and is
not intuitive. Adding this feature won't cause feature creep but would
rather add an operation that makes sense in some scenarios and reduces
the
On 4 February 2013 23:14, Robert Clausecker fuz...@gmail.com wrote:
The specific workflow I am planning is this:
I have a server that hosts a bare git repository. This git repository
contains a branch production. Whenever somebody pushes to production a
hook automatically puts a copy of the
Andrew Ardill andrew.ard...@gmail.com writes:
On 4 February 2013 23:14, Robert Clausecker fuz...@gmail.com wrote:
The specific workflow I am planning is this:
I have a server that hosts a bare git repository. This git repository
contains a branch production. Whenever somebody pushes to
Robert Clausecker fuz...@gmail.com writes:
I have a server that hosts a bare git repository. This git repository
contains a branch production. Whenever somebody pushes to production a
hook automatically puts a copy of the current production branch
into /var/www/foo. I could of course use pull
Hello!
git currently has the archive command that allows to save an arbitrary
revision into a tar or zip file. Sometimes it is useful to not save this
revision into an archive but to directly put all files into an arbitrary
directory. Currently this seems to be not possible to archive directly;
On 02/03/2013 07:48 PM, Robert Clausecker wrote:
Hello!
git currently has the archive command that allows to save an arbitrary
revision into a tar or zip file. Sometimes it is useful to not save this
revision into an archive but to directly put all files into an arbitrary
directory.
Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:
Could you help me understand why piping it to tar (actually 'tar -C
/dest/dir -x') is not sufficient to achieve what you want?
Piping the output of git archive into tar is of course a possible
solution; I just don't like the
On Sun, Feb 03, 2013 at 03:18:05PM +0100, Robert Clausecker wrote:
git currently has the archive command that allows to save an arbitrary
revision into a tar or zip file. Sometimes it is useful to not save this
revision into an archive but to directly put all files into an arbitrary
On 02/03/2013 11:41 PM, Robert Clausecker wrote:
Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:
Could you help me understand why piping it to tar (actually 'tar -C
/dest/dir -x') is not sufficient to achieve what you want?
Piping the output of git archive into tar is of
Hey folks,
When I checked for false positives in my spam this morning, I spotted
an interesting malformed img link at the top of a spam message.
{snip}
http://git.{snip}.n2.nabble.com/file/{snip}/t3.jpg
Employ a medal tiffany bracelet {snip} a is
{snip}
So, apparently git-daemon's http
On Thu, Jan 31, 2013 at 1:46 PM, porpen+...@gmail.com wrote:
Hey folks,
When I checked for false positives in my spam this morning, I spotted
an interesting malformed img link at the top of a spam message.
{snip}
http://git.{snip}.n2.nabble.com/file/{snip}/t3.jpg
Employ a medal tiffany
to take up with the nabble staff.
Agreed.. and I won't waste my time with nabble. I'll just set
procmeil to file new threads from nabble into a penalty box for now
and start a whitelist. Perhaps I'll come up with something more
elegant/automated later.
So, I guess my feature request is resolved
-Original Message-
From: git-ow...@vger.kernel.org
[mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo
Sent: Monday, January 28, 2013 3:16 PM
To: Junio C Hamano
Cc: Michael J Gruber; wookietreiber; git@vger.kernel.org
Subject: Re: [feature request] git add completion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/01/2013 15:06, Marc Khouzam ha scritto:
[...]
I will try to update the patch, with your latest suggestions (avoid
tricky POSIX shell syntax, and CDPATH issue - if I remember
correctly),
and with an update for the t/t9902-completion.sh test
-Original Message-
From: git-ow...@vger.kernel.org
[mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo
Sent: Wednesday, January 30, 2013 1:24 PM
To: Marc Khouzam
Cc: 'Junio C Hamano'; 'Michael J Gruber'; 'wookietreiber';
'git@vger.kernel.org'
Subject: Re: [feature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/01/2013 19:55, Marc Khouzam ha scritto:
[...]
The new logic in git-completion.bash tells bash that 'filenames'
completion is ongoing so bash will add a '/' after directories.
Sadly, tcsh won't do that, so it would be simpler if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
wookietreiber kizkizzbangb...@googlemail.com writes:
I have a feature request for `git add` auto completion:
`git add` auto completion suggests all files / directories,
filtered by nothing. I
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
wookietreiber kizkizzbangb...@googlemail.com writes:
I have a feature request for `git add` auto completion:
`git add` auto completion suggests all files / directories,
filtered by nothing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 13:52, Michael J Gruber ha scritto:
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
wookietreiber kizkizzbangb...@googlemail.com writes:
I have a feature request for `git add
Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
Il 28/01/2013 13:52, Michael J Gruber ha scritto:
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
wookietreiber kizkizzbangb...@googlemail.com writes:
I have a feature request for `git
Michael J Gruber g...@drmicha.warpmail.net writes:
Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
Please, test it and report any behaviour you think is incorrect.
OK, that seems to work and to be quite helpful.
Minor nit: git add -u could use the same fileset as git commit. But
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 17:22, Michael J Gruber ha scritto:
[...]
The patch will suggest (for git add command), all the files that are
candidate to be added to the index file.
Please, test it and report any behaviour you think is incorrect.
OK, that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 18:52, Junio C Hamano ha scritto:
[...]
Thanks both for commenting. I'll find time to read it over again
and perhaps we can merge it to 'next' and advertise it in the next
issue of What's cooking report to ask for wider testing to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Many C projects I have seen (based on autoconf, but not always - like
Nginx) allow the project to be build in a separate directory, in order
to avoid to pollute the working directory with compiled files.
Unfortunately this seems to not be
Hi Manlio,
Manlio Perillo wrote:
Many C projects I have seen (based on autoconf, but not always - like
Nginx) allow the project to be build in a separate directory, in order
to avoid to pollute the working directory with compiled files.
Unfortunately this seems to not be possible with Git.
[mailto:chris.rorv...@gmail.com] On Behalf Of
Chris Rorvick
Sent: Sunday, 9 December 2012 4:54 PM
To: Matthew Ciancio
Cc: git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio
matthew.cianci...@gmail.com wrote:
Hi Chris
Chris Rorvick ch...@rorvick.com writes:
It's not in branchA, it's just no longer ignored because your changes
to .gitignore were effectively reverted by jumping back to the commit
that branchA points to.
...
hide/reappear is the equivalent to saying deleted/created in the
case of a tracked
2012 8:04 PM
To: Chris Rorvick
Cc: Matthew Ciancio; git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
Chris Rorvick ch...@rorvick.com writes:
It's not in branchA, it's just no longer ignored because your changes
to .gitignore were effectively reverted by jumping
Hi Matt,
On 8 December 2012 11:50, Matthew Ciancio matthew.cianci...@gmail.com wrote:
Problem: ignore.txt does not disappear like foo.txt does and is now just
sitting in branchA (and now any other branch I checkout into).
When I first started using Git, I genuinely thought this was a bug,
..
-Original Message-
From: Andrew Ardill [mailto:andrew.ard...@gmail.com]
Sent: Monday, 10 December 2012 12:46 PM
To: Matthew Ciancio
Cc: git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
Hi Matt,
On 8 December 2012 11:50, Matthew Ciancio matthew.cianci
On Fri, Dec 7, 2012 at 6:50 PM, Matthew Ciancio
matthew.cianci...@gmail.com wrote:
Imagine this scenario:
1) You have a Git repo with two branches (branchA and branchB), which are
currently identical.
2) Checkout to branch.
3) Create file foo.txt, stage it and commit it.
4) Create file
On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio
matthew.cianci...@gmail.com wrote:
Hi Chris,
Yes, I don't think I have explained myself well enough.
When I say disappear I do not mean get deleted, I mean: go out of view
just like foo.txt does, as it is committed to branchB and not merged
messy.
Do you think this warrants a feature request?
If so, I was thinking that maybe the .gitignore file could have a flag after
each entry, to indicate whether the file(s)/folder(s) should have this new
feature or not (that way it would cater for everyone, but I can't see why
you wouldn't want
Am Tue, 16 Oct 2012 13:36:04 +0200
schrieb Angelo Borsotti angelo.borso...@gmail.com:
Hello,
some VCS, e.g. ClearCase, allow to control the fetching of files so as
to warn, or
disallow parallel changes to the same files.
As of today, there is no way to implement the same kind of workflow
Hi Andrew,
one nice thing is to warn a developer that wants to modify a source
file, that there is somebody else changing it beforehand. It is nicer
than discovering that at push time.
Take into account that there are changes in files that may be
incompatible to each other, or that can be
On Tue, Oct 16, 2012 at 10:57 PM, Angelo Borsotti
angelo.borso...@gmail.com wrote:
Hi Andrew,
one nice thing is to warn a developer that wants to modify a source
file, that there is somebody else changing it beforehand. It is nicer
than discovering that at push time.
Andrew:
also see
On 17 October 2012 04:27, Angelo Borsotti angelo.borso...@gmail.com wrote:
Hi Andrew,
one nice thing is to warn a developer that wants to modify a source
file, that there is somebody else changing it beforehand. It is nicer
than discovering that at push time.
Take into account that there are
Hi, Git
Change this:
# git status
# On branch yandex_mail_new_api
# Your branch is ahead of 'origin/yandex_mail_new_api' by 2 commits.
#
# Changes not staged for commit:
# (use git add file... to update what will be committed)
# (use git checkout -- file... to discard changes in working
On Tue, Sep 4, 2012 at 7:25 PM, Коньков Евгений k...@reg.ru wrote:
sot this allow:
git diff 1 same asgit diff a1.txt
git diff 2 same asgit diff a2.txt
git add 1same asgit add a1.txt
in case there are may be files with such names I may appply option
Коньков Евгений k...@reg.ru writes:
# git status
# On branch yandex_mail_new_api
# Your branch is ahead of 'origin/yandex_mail_new_api' by 2 commits.
#
# Changes not staged for commit:
# (use git add file... to update what will be committed)
# (use git checkout -- file... to discard
Well I actually didn't know about stash -p when I asked for this, but I
still see room for us removing some more friction here:
# start from N-commit worth of change, debug and WIP
git stash save -p debug ;# stash away only the debugging aid
# now we have only N-commit worth of
On Thu, Aug 16, 2012 at 04:22:54PM -0700, Junio C Hamano wrote:
In the meantime, would it make sense to introduce a configuration
variable to request this behavior?
If so, should it be global?
fetch.prune = always
or per-remote?
remote.name.prune = always
The global option
Jared Hance jaredha...@gmail.com writes:
[administrivia: do not deflect a direct response to you away by
using mail-followup-to header, thanks]
On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote:
Something like git commit --fixup HEAD~3, where git commit --fixup HEAD
would be
With git's commit frequently style, I often find that I end up with a
commit that includes a typo in a comment or I forgot one call site when
updating functions or something.
And it's a few commits later before I notice the simple oops.
This is of course fixable by making a commit, rebase -i
On 08/17/2012 05:47 PM, George Spelvin wrote:
With git's commit frequently style, I often find that I end up with a
commit that includes a typo in a comment or I forgot one call site when
updating functions or something.
And it's a few commits later before I notice the simple oops.
This is of
On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote:
Something like git commit --fixup HEAD~3, where git commit --fixup HEAD
would be equivalent to git commit --amend.
Aside from the ways others mentioned on how to do this, I think that a
better interface if this were to be added
Dan Johnson computerdr...@gmail.com writes:
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King p...@peff.net wrote:
...
So I think it would be a lot more palatable if we kept reflogs on
deleted branches. That, in turn, has a few open issues, such as how to
manage namespace conflicts (e.g., the fact
401 - 500 of 532 matches
Mail list logo
