[git-users] Re: [PATCH] build: add default configuration
Felipe Contreras felipe.contre...@gmail.com wrote: I know 'git ci' is perfectly fine shortcut to 'git commit'. Either way, it doesn't matter. Even if we agree that /etc/gitconfig.d is what we want, or we add an /usr/share/git/config, Junio is not going to apply any patch, even if it's what most users want. Please stop making personal attacks that add nothing to your argument. No one cares. Let it be. Let's move this in a more constructive direction then, no? How about working on documenting the new aliases and add a knob to the Makefile so that we can choose whether or not to install the stock config? I'm not trying to fight this patch -- the idea is nice. Most users and distros probably won't change stock aliases, so your energy may be better spent getting consensus on what the stock aliases could be. Would it not be better to have these aliases, plus/minus one or two, then none at all? ... Yes I know about .rpmsave files. For rpm, it'll refuse to upgrade Git since this new file will conflict with an existing package. That's easier to deal with because the config package can then be independently modified to install its file to eg git.d/foo.conf in the directory include example. That would then allow the upgrade, and at no point did the intended config ever get lost. Puppet users, for example, may end up with rpmsave turds on their systems, though. When you are managing lots of machines this can be very annoying -- that's why I mentioned it. Don't bother arguing this point any further. It's boring. ... In summary -- makefile knob, please, and at least mention the stock aliases somewhere in the docs so that the users can know to read /etc/gitconfig if they want to know more. Who knows, maybe it will get applied, but it definitively won't if all you do is whine about it. -- David -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: [PATCH] build: add default configuration
On Sat, Sep 21, 2013 at 1:33 AM, David Aguilar dav...@gmail.com wrote: Felipe Contreras felipe.contre...@gmail.com wrote: I know 'git ci' is perfectly fine shortcut to 'git commit'. Either way, it doesn't matter. Even if we agree that /etc/gitconfig.d is what we want, or we add an /usr/share/git/config, Junio is not going to apply any patch, even if it's what most users want. Please stop making personal attacks that add nothing to your argument. No one cares. Let it be. There are no personal attacks here. A personal attack would be 'X is a moron', or 'X doesn't know what he is talking about', I don't see any of that. This is a fact, do you see anybody besides you and me commenting about the subject? More specifically, do you see Junio making any comment? Let's move this in a more constructive direction then, no? How about working on documenting the new aliases and add a knob to the Makefile so that we can choose whether or not to install the stock config? Sure, but document these aliases where? If you mean document them in the man page of each command (e.g. git commit, alias: ci), then sure, that's fine by me. Adding a know to the Makefile I think doesn't make sense, because a packager would do. % make NO_DEFAULT_CONFIG=y install Which is not very different from: % make install % rm -f $DESTDIR/etc/gitconfig I'm not trying to fight this patch -- the idea is nice. Most users and distros probably won't change stock aliases, so your energy may be better spent getting consensus on what the stock aliases could be. Thanks for stating so, unfortunately, I don't think it really matters because this is a change, and the Git project is not welcome to change. Would it not be better to have these aliases, plus/minus one or two, then none at all? Yes, but you don't see anybody advocating for that at all, do you? ... Yes I know about .rpmsave files. For rpm, it'll refuse to upgrade Git since this new file will conflict with an existing package. In your case, yes, not in the normal case, where /etc/gitconfig is not provided by a package. That's easier to deal with because the config package can then be independently modified to install its file to eg git.d/foo.conf in the directory include example. That would then allow the upgrade, and at no point did the intended config ever get lost. It might be easier to deal with, but it would still require an intervention. Puppet users, for example, may end up with rpmsave turds on their systems, though. When you are managing lots of machines this can be very annoying -- that's why I mentioned it. Don't bother arguing this point any further. It's boring. It can be very annoying, but your /etc/gitconfig.d solution doesn't help in that regard. Either way, the move from 'git-foo' to 'git foo' was very annoying as well, but we all agreed it was the right thing to do (most of us), fortunately in this case I think the people that have a /etc/gitconfig are significantly less. ... In summary -- makefile knob, please, and at least mention the stock aliases somewhere in the docs so that the users can know to read /etc/gitconfig if they want to know more. Who knows, maybe it will get applied, but it definitively won't if all you do is whine about it. It won't get applied, I'll do the modifications, and you'll see. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] git rebase keeps giving the conflict
hi, i cloned a new tree, made changes to file readme.txt meantime readme.txt in the remote has changed at the same location. when i do a git pull i got merge conflicts, i resolved the conflicts and did a 'git commit' now i did git rebase, somehow i'm seeing the conflict again, now i fixed the conflict and did 'git rebase --continue' the conflict shows up agiain, how can i get around this, am i doing something wrong, or is there a bug in git ? any help appreciated. -dexter -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] git rebase after a pull
is it required to do a git pull before doing a git push. and is it required to do a git rebase after git pull just before git push. one of my git repo mandates the above wondering if there is a valid reason for this. -dexter -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git rebase after a pull
Dexter,
It is not required that you Pull before a push. The pull is a combination of
'fetch' and 'merge'. So you can fetch the remote content into it's own area of
storage, and then compare what you have with what they have - gitk branch
is useful here. (the '' means return immediately, so you can still use your
bash while interacting with the Gitk gui, perhaps running another gitk, or git
gui etc)
Often (in some cases) you will want to simply update their head pointers, and
then rebase your work on their new head. Howver individual uses vary
I either use the 'git push . ref:ref for branches I'm not on, or git reset
--hard @{upstream} to move the current branch to match it's remote (I will
have created a branch for my work so I'm not 'loosing' that).
Philip
- Original Message -
From: dexter ietf
To: git-users@googlegroups.com
Sent: Saturday, September 21, 2013 2:06 PM
Subject: [git-users] git rebase after a pull
is it required to do a git pull before doing a git push.
and is it required to do a git rebase after git pull just
before git push. one of my git repo mandates the
above wondering if there is a valid reason for this.
-dexter
--
You received this message because you are subscribed to the Google Groups
Git for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[git-users] assume unchanged bit operations
Hi,
Git allows to set the assume unchanged bit to a tracking file. It
helpfull for example when you work with Eclipse Java projects and don't
want your local changes in the project configuration files to be tracked by
git. Unfortunatelly I didn't find a convenient way of listing files with
this bit set. The only way to listem them is by commands like following:
git ls-files -v | grep ^[a-z]
git ls-files -v | awk '{if (match($1, [a-z])) print $2}'
This is unhandy and not obvious. Is there a convinient way of doing it by git?
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] assume unchanged bit operations
In some case the use of the .gitignore to identify which types of files are not
relevant is better.
That said, git does not (yet) have any mechanism for marking files as
'precious' but untracked. It takes the view that precious files should be
tracked
Philip
- Original Message -
From: Rostislav Krasny
To: git-users@googlegroups.com
Sent: Saturday, September 21, 2013 2:54 PM
Subject: [git-users] assume unchanged bit operations
Hi,
Git allows to set the assume unchanged bit to a tracking file. It helpfull
for example when you work with Eclipse Java projects and don't want your local
changes in the project configuration files to be tracked by git. Unfortunatelly
I didn't find a convenient way of listing files with this bit set. The only way
to listem them is by commands like following:
git ls-files -v | grep ^[a-z] git ls-files -v | awk '{if (match($1, [a-z]))
print $2}'This is unhandy and not obvious. Is there a convinient way of doing
it by git?
--
You received this message because you are subscribed to the Google Groups
Git for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] assume unchanged bit operations
On Saturday, September 21, 2013 5:20:12 PM UTC+3, Philip Oakley wrote: In some case the use of the .gitignore to identify which types of files are not relevant is better. This is not the case. That said, git does not (yet) have any mechanism for marking files as 'precious' but untracked. It takes the view that precious files should be tracked It already has a mechanism for marking files similarly. It luck a mechanism of listing such files. Anyway and for any use case there should be a convinient way to get a list of files marked by some special bit. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git rebase after a pull
On Sat, Sep 21, 2013 at 8:06 AM, dexter ietf dexter.i...@gmail.com wrote: is it required to do a git pull before doing a git push. and is it required to do a git rebase after git pull just before git push. one of my git repo mandates the above wondering if there is a valid reason for this. Only if your local changes have diverged. You have to either merge or rebase. 'git pull' by default does a merge, but you can force it to do a rebase: 'git pull --rebase'. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: git5 submit bypassing tap
On Friday, September 20, 2013 11:34:14 AM UTC+2, Rajnish Kumar wrote: Hi, Just tried submitting a CL using TAP, which ran 422 test cases and had 7 failures. These failures have been verified to be caused by a recent change. Now I wish to submit the CL without going through TAP to avoid running these test once again. 'git5 submit' used to work earlier but it does not seem to work anymore. Is there any way to submit the CL without running the tests once again? I like to think of myself as a proficient Git user, but I didn't get a single one of those acronyms. What are you talking about? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
