On Wed, Aug 06, 2014 at 05:38:43PM -0700, Mike Stump wrote:
Oh, wait, maybe I have misunderstood the prohibition. I have:
upstream —— fsf
|
\
|
v
Me — master — coworker.
This looks a lot like what I meant about project repos.
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
I have been fiddling around in this area.
What I want to be able to do is develop fixes for open source code
that I run, and get those fixes upstream. This means I need a rebasing
workflow, to keep the patches up-to-date and to deal
On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
Nico Williams n...@cryptonector.com wrote:
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
But [a rebasing workflow] is inconvenient for deploying the patched
version to production (which is the point of developing
On Thu, Aug 7, 2014 at 12:47 PM, Tony Finch d...@dotat.at wrote:
Nico Williams n...@cryptonector.com wrote:
Either way I retain the old HEAD with some name.
Hmm, yes, I can see that would work. However my previous workflow was
rather branch-heavy and I found the accumulation of names annoying
On Thu, Aug 7, 2014 at 6:38 AM, Tony Finch d...@dotat.at wrote:
So I have a small tool which maintains a publication branch which tracks
the head of a rebasing branch. It's reasonably satisfactory so far...
https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git
... though the structure of the
On Fri, Aug 08, 2014 at 10:34:43AM -0700, Mike Stump wrote:
On Aug 6, 2014, at 10:11 PM, Nico Williams n...@cryptonector.com wrote:
Nah. Sun managed this for decades without a hitch, and for products
much larger than GCC. See above.
Ok. Ah, ok, perfect. I see how that method of working
IIUC, this might help,
http://www.mail-archive.com/git@vger.kernel.org/msg56418.html
http://www.mail-archive.com/git@vger.kernel.org/msg56468.html
--
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
On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote:
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My
No code == no substance might be a stretch, but definitely fair enough.
I thought the idea was clear enough, but I can flesh it out if
desired. The particular advantage I saw in it is that it would reuse
the existing object infrastructure, and extend to branches the
first-class treatment that
[I'm a list newbie here, but a git power user.]
If branches were objects...
- one could see the history of branches, including
- how commits were grouped when pushed/pulled (push 5 commits, and
the branch object will record that its head moved by those five
commits at once)
- rebase history
On Thu, Jun 19, 2014 at 6:46 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Nico Williams wrote:
- one could see the history of branches, including
Interesting. 'git log -g' is good for getting that information
locally, but the protocol doesn't have a way to get it from a remote
server so
Another thing is that branches as objects could store a lot more
information, like:
- the merge-base and HEAD for a rebase (and the --onto)
- the interactive rebase plan! (and diffs to what would have been
the non-interactive plan)
- the would-be no-op non-interactive rebase plan post
On Fri, Jun 20, 2014 at 1:53 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
[...]
Hmph, but that obviously will become very expensive to compute as
project grows.
That's the main reason to like Fossil's approach (namely, the use of
SQL, specifically
(thinking more about this, digesting Jonathan's response...)
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but all
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote:
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
Now, suppose that branches were objects. Then at push time one might
push with a message about the set of commits being pushed, and this
message (and time
On Mon, Jul 14, 2014 at 6:31 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong normalper...@yhbt.net wrote:
Torsten Bögershausen tbo...@web.de wrote:
You're saying this as if Windows is a single-user system. It's not,
but it uses ACLs rather than POSIX
Still, git might like to know what ACLs to apply to files at checkout
time. That would be a vast new feature, I think, and probably not
worth it, particularly since that would require dealing with the
different types of ACLs: NTFS/NFSv4/ZFS on the one hand, POSIX Draft
on the other, plus AFS
On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Sergei Organov wrote:
Is there any scenario at all where pull --rebase=true wins over
preserve?
Basically always in my book. ;-)
When people turn on 'pull --rebase', they are asking for a clean,
simplified history
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov o...@javad.com wrote:
Nico Williams n...@cryptonector.com writes:
That exception aside, keeping all local commits on top by always
rebasing them onto the upstream is extremely useful: a) in simplifying
conflict resolution, b) making it easy
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley philipoak...@iee.org wrote:
From: Nico Williams n...@cryptonector.com
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
upstreams (the example exception I gave
On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley philipoak...@iee.org wrote:
From: Nico Williams n...@cryptonector.com
That workflow works just fine with git.
I'm not saying that it isn't a good technique and can work well. Rather I'm
saying we should be tolerant of the rules and techniques
(or all of a repo's branches)
Teamware recorded whether it had any children and warned about
rebasing published contents. Perhaps git could do the same.
Nico
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov o...@javad.com wrote:
Nico Williams n...@cryptonector.com writes:
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
upstreams (the example exception I gave
On Friday, August 1, 2014, Dennis Kaarsemaker den...@kaarsemaker.net wrote:
On di, 2014-07-29 at 17:40 -0500, Nico Williams wrote:
(or all of a repo's branches)
Teamware recorded whether it had any children and warned about
rebasing published contents. Perhaps git could do the same
On Thursday, July 31, 2014, Mike Stump mikest...@comcast.net wrote:
Cherry picking doesn’t work as well as it should. I was testing on git
version 1.7.9.5.
Put in a line in a file, call it:
first version
then cherry pick this into your branch. Then update on master and transform
that
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Jonathan Nieder wrote:
Do you mean that git merge should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate
That said, when today's git merge fails to resolve conflicts, it's
On Fri, Aug 1, 2014 at 4:44 PM, Junio C Hamano gits...@pobox.com wrote:
Nico Williams n...@cryptonector.com writes:
Cherry-picks should record two parents, like merges.
No.
It is OK to record where it came from, and we let you do so with the
-x option.
But the where it came from commit
On Fri, Aug 1, 2014 at 5:13 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 1, 2014, at 12:22 PM, Nico Williams n...@cryptonector.com wrote:
If you always rebase
I can’t use rebase unless you make rebase work with multiple users and
pushing pulling.
That works now, and I do it all
On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 1, 2014, at 1:12 PM, Sam Vilain s...@vilain.net wrote:
Git merge has a notion of discrete merge strategies”.
There's no particular reason that you couldn't implement a merge
strategy which works more like SVN's
Personally (a user of, not a maintainer of, git) I really want some
alternative backends. In particular I'm after something like Fossil's
use of SQLite3; I want a SQLite3 backend for several reasons, not the
least of which is the power of SQL for looking at history.
I'm not sure that I
Excellent. Thanks!
--
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-info.html
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 2014-08-01 22:55, Nico Williams pisze:
It would help if cherry-pick history where recorded somewhere (beyond
the reflog)...
Cherry-picks should record two parents, like merges.
(Of course, it does no good to know
On Wed, Aug 06, 2014 at 12:11:16PM -0700, Mike Stump wrote:
On Aug 1, 2014, at 4:40 PM, Nico Williams n...@cryptonector.com wrote:
As for rebase, I still don't understand why it doesn't work for you.
http://git-scm.com/docs/git-rebase says:
Rebasing (or any other form of rewriting
On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams n...@cryptonector.com wrote:
My proposal was to put this sort of ancillary history info in a
branch object (and that branches should be objects). This would
have a number
On Wed, Aug 06, 2014 at 02:44:59PM -0500, Nico Williams wrote:
That means that you have/maintain an intermediate upstream, yes?
This is a bit trickier since once in a while that intermediate upstream
and everyone downstream of it has to catch up with the real upstream.
Here you have two
Is there a plan for upgrading to a better hash function in the future?
(E.g., should it become an urgent need.)
What are the roadblocks to adoption of a replacement hash function?
Just documenting this would go a long way towards making it possible
to upgrade some day.
Thanks,
Nico
--
--
To
On Tue, Jan 20, 2015 at 10:38:40PM +0100, Noralf Trønnes wrote:
Yes:
$ echo Noralf Trønnes | xxd
000: 4e6f 7261 6c66 2054 72f8 6e6e 6573 0aNoralf Tr.nnes.
Is there a command I can run that shows that I'm using ISO-8859-1 ?
I need something to google with, my previous search only
37 matches
Mail list logo
